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(54) A technique for license management and online software license enforcement 



(57) A software protection is presented comprising 
software license management and online software li- 
cense enforcement, wherein individual licenses are pro- 
vided for regulating the use of a software product, and 



the software product is individualised while being down- 
loaded from a license server, and the execution of each 
individualised software product is monitored in agree- 
ment with the individual license terms corresponding to 
the individual software download. 
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Description 

[0001] The present invention relates to techniques for 
preventing fraudulent use of software products. In par- 
ticular, the present invention provides a license man- 5 
agement system and a technique for enforcing the use 
of a software product according to the corresponding li- 
cense terms. 

[0002] One of the most significant problems in soft- 
ware distribution is the protection of the rights of soft- 
ware producers and other subjects involved in software 
distribution. The subject holding the rights on a software 
product is very often distinct from the actual producer of 
it. Therefore, the subject owning the rights on a software 
product will be referred to as software supplier in the 
context of this application. Further, within the process of 
software distribution a subject acquiring licenses for a 
software product from a supplier and reselling those li- 
censes to other distributors, dealers or end-users is de- 
fined as a distributor in this context. Hereby, the term 
dealer describes a subject which acquires licenses for 
further reselling them to other dealers or end-users, and 
an end-user is defined as a subject, which acquires a 
license on a software product for utilising it. 
[0003] The pricing scheme of a software product usu- 
ally does not comprise only a single value, but a list of 
graduated prices reflecting considerations like the vol- 
ume of an order and/or the number of installations of a 
software product already in use at a customer's site and/ 
or if the customer is a governmental, commercial or ed- 
ucational end-user. This price range very often forms an 
incentive for fraud. For example, a price for an educa- 
tional copy of a software product is usually calculated to 
be just a small fraction of the price to be paid for a copy 
of the same software product sold for commercial use. 
Dealers are therefore frequently tempted to sell a copy 
of a software product to a commercial end-user which 
has explicitly been acquired by the dealer at a substan- 
tially lower price for an educational end-user. 
[0004] Another annoyance for software suppliers is 
software pirating and the distribution of bootlegs, which 
considerably reduces the achievable revenue. Software 
pirates prefer to act in countries where it is very difficult 
for a software supplier to get legal support in prosecuting 
malicious subjects. In the era of world-wide data trans- 
fer, software pirates can act from countries in which a 
software supplier does not get any legal support for 
stopping their wrongdoing. Therefore, a software sup- 
plier will in many cases be unable to enforce his license 
terms. A known approach for solving this problem is the 
integration of mechanisms in a software product, which 
makes it difficult for malicious subjects to create a boot- 
leg of that software product. 

[0005] A common way of realising a protection mech- 
anism against software pirating is to apply a mark to the 
software distribution medium like e.g. floppy discs or 
CD-ROMs such, that it will be very difficult for a mali- 
cious subject to reproduce the mark on an illicit copy. 



Verification code is added to the software, which checks 
if the software is being run from the original distribution 
medium as soon as the user tries to run the software. 
Usually, this is done by searching the medium from 
which the software is being loaded for the mark that was 
applied by the software producer or supplier. If such a 
mark cannot be found, a continued program execution 
will be refused. 

[0006] In the context of this application the term "ver- 
ification code" generally refers to a piece of code and/ 
or corresponding data contained in a piece of software 
that is suited to assist in protecting rights on the piece 
of software. 

[0007] To outsmart a protection mechanism of the 
kind described, a software pirate can either copy the 
mark or remove the verification code. At copying the 
mark, the illicit copy is made looking exactly the same 
to the verification code as the original distribution medi- 
um. Alternatively, the protection mechanism can be 
eliminated by reverse engineering the software with the 
purpose of discovering the verification code and how it 
interacts with the remaining code. On successful re- 
verse engineering, the verification code can finally be 
deactivated or removed completely. This secondly de- 
scribed method is generally referred to as "cracking". A 
"cracked" copy would not have to bear the mark, be- 
cause a "cracked" version of the software would not 
check for its presence. 

[0008] A software supplier may alternatively to the de- 
scribed method require an end-user to register his soft- 
ware product and to pay the due license fee. According 
to one variant of this model, a supplier will send a key 
file to the requesting end-user who in turn stores this file 
on his computer. Verification code embedded in the soft- 
ware will prevent, that a malicious subject can run the 
software without a key file. However, a software pirate 
can try to reverse engineer the format of the key file and 
generate one of his own. This is an equivalent to the 
copying of a mark as described above. Of course, a soft- 
ware pirate may alternatively also in this case deactivate 
the verification code from the software, so that the soft- 
ware can be run without a key file. 
[0009] Both types of attacks, copying marks or gen- 
erating key files on one side and "cracking" on the other 
side are in wide-spread use and cannot be fully defend- 
ed against. A software producer can only try to discour- 
age any attempt of "cracking" his software by making 
the process of reverse engineering and other forms of 
attack as difficult as possible by obfuscating the inner 
workings of his software. 

[001 0] Recently, a method used to protect media like 
digital images and video-audio recordings has been pro- 
posed to be applied to the field of software protection. 
Hereby, a secret message, a so-called watermark is hid- 
den within the software product. Due to the fact that such 
watermarks may only be removed easily by someone 
who is in possession of the hidden secret used for the 
construction of the watermark, this technique provides 
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a high level of software protection. 
[0011] WO 99/64973 proposes a software water- 
marking technique wherein the watermark is formed by 
a special executional state of the software. When pro- 
vided with a secret input sequence, the software appli- 
cation enters a state which in itself represents the wa- 
termark, whereby the state is comprised of data in the 
stack, heap, global variables, registers, program 
counters and the like of the software application. In other 
words, the watermark is constructed within the dynam- 
ically allocated data structures of the program as it is 
being executed. Like above, an attacker may employ re- 
verse engineering to identify the watermark generating 
code. He might then remove the generating code and 
thus the watermark from the software product. The sug- 
gested canonical use of the watermark is a fingerprinting 
of the product. Fingerprinting means, that each individ- 
ual copy of the software product is uniquely water- 
marked, thus allowing an identification of each particular 
copy of a software product. In other words, by the meth- 
od of fingerprinting each individual copy of the software 
product is watermarked with a different watermark. But 
still, an attack of an adversary cannot be fully defended 
against. 

[0012] Another approach to prevent abuse of utilisa- 
tion regulations is to monitor the use of a software prod- 
uct. In this context US 5 925 127 proposes a system, 
wherein acheckin/check-out module installed on a com- 
puter running the software product provides the licens- 
ing information and a software monitor module running 
on the same machine verifies a usage of the software 
program module according to the license conditions. 
The proposed system is especially used for monitoring 
the use of rented software. 

[0013] The system proposed in WO 99/04354 sug- 
gests a license management system for software, 
wherein an application program requests a license from 
a license management unit which re-checks the request 
with a number of license decision units. In case, a li- 
cense cannot be issued to a copy of an application pro- 
gram, this copy cannot be executed. 
[001 4] Although those systems check certain param- 
eters like e.g. "is there a license?", "Are all licenses used 
up?" or "Is there an attempt to use the program beyond 
the expiration date of the license?", a correct usage of 
the software program according to a contractual provi- 
sion - apart from the requirement that a license must 
exist at the site of the enduser - cannot be guaranteed. 
Further, no provisions are suggested for warding off 
common impersonation attacks, where a malicious user 
sets up a fake license management unit unconditionally 
granting the execution of the application program, or re- 
play attacks, where messages sent by the license man- 
agement unit are recorded and later replayed for allow- 
ing an application program to execute without actually 
having to contact the license management unit. 
[0015] Moreover, existing systems typically imple- 
ment the license storage in a component that is acces- 



sible to the user of a piece of software, e.g. in the form 
of a software module installed on the same computer as 
the licensed piece of software or another computer ac- 
cessible to the licensee. This enables a malicious user 

5 to attack the license enforcement mechanism by manip- 
ulating the component such, that it unconditionally con- 
firms the presence of a license, even if no valid license 
exists for a certain software product. 
[0016] In addition, existing protection systems typical- 

10 |y require the programmer to add support for license en- 
forcement, e.g. verification code, to his program manu- 
ally. However, since most programmers are not security 
experts and hence not aware of how an attacker works, 
they do so in a way that greatly simplifies "cracking" their 

is software. 

[001 7] It is therefore an object of the present invention 
to provide secure methods and systems for software 
distribution, protecting the rights of the software supplier 
and the rights of all subjects involved in a distribution 
20 process. 

[0018] This object is achieved by a method for soft- 
ware license management and online software license 
enforcement comprising the steps of providing individ- 
ual licenses for regulating the use of a software product, 
25 controlling a transfer of licenses, providing individual- 
ised copies of the software product for download, and 
monitoring the execution of each individualised copy of 
the software product in agreement with the individual li- 
cense terms. 

30 [0019] The above object is further achieved by a 
method of modifying one or more files of a software 
product, particularly in conjunction with the above de- 
scribed method for software license management, 
whereby the modifying is at least partly based on infor- 
ms mation extracted from at least a part of data of one or 
more initial and/or intermediate and/or final states of the 
creation process of the software product. 
[0020] The above object is further achieved by a li- 
cense management software program comprising the 
40 steps of providing licenses, and controlling a transfer of 
licenses. 

[0021] Further, the object is achieved by a download 
control software program for providing an individual 
download copy of a software product by individually 
45 modifying a copy of a master-copy of the software prod- 
uct for download from a server according to a method 
of modifying one or more files of a software product as 
described above. 

[0022] The object is further achieved by an execution 
50 control software program for linking an individual down- 
load copy of a software product requesting permission 
to run to a matching license, comprising the steps of ob- 
taining identification information from the individual 
download copy before or while it is being executed, eval- 
55 uating licenses matching the identification information, 
and if at least one of the licenses grants use of the indi- 
vidual download copy, transmitting approval to the indi- 
vidual download copy. 
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[0023] Furthermore the above object is achieved by 
an individual download copy of a software product cre- 
ated by individually modifying a copy of a master-copy 
of the software product for download from a server ac- 
cording to a method of modifying one or more files of a 5 
software product as described above. 
[0024] In addition, the object is achieved by a server 
for providing a software license management and an on- 
line software license enforcement in accordance to one 
of the methods described above, comprising means for 
the application of a license management software pro- 
gram, and/or a download control software program, and/ 
or an execution control software program. 
[0025] The proposed method of a provision of licens- 
es and an individualisation of the licensed software 
products on delivery and a further monitoring of the ex- 
ecution of the software products subject to a license pro- 
vided, all in one system allows for one an effective con- 
trol of distribution lines and beyond this ties the use of 
a software product to the conditions agreed to in an un- 
derlying license contract. Furthermore, it provides a high 
level of protection against attackers with the specific in- 
tent to circumvent the license terms by inhibiting imper- 
sonation and replay attacks and any tampering with the 
program code. Because licenses are provided on an in- 
dividual basis, the system is able to support a variety of 
different licensing and distribution schemes. 
[0026] Further advantageous features are claimed in 
the respective subclaims. 

[0027] The individualisation step advantageously in- 
cludes embedding information in the individualised cop- 
ies of the software product. Further advantageously, the 
individualisation step generates a uniquely individual- 
ised copy the software product for each download. Par- 
ticularly advantageously, each subject joining the pro- 
cedure of software license management and online soft- 
ware license enforcement is subject to register prior to 
being granted access, so that each license can be linked 
to its licensee. 

[0028] Modifying files of a software product preferably 
comprises embedding information in at least one of said 
files, since the embedded information is easy to locate 
and identify by the party that performed the embedding. 
The modifying is advantageously at least partly based 
on information extracted from at least a part of data of 
one or more object files generated during the creation 
process of the software product, thereby allowing easy 
modification of files without any knowledge of the source 
code. In addition to that, the modifying is preferably at 
least partly based on information extracted from at least 
a part of the debug information, for debug information is 
comparatively uncomplicated to process and the capa- 
bility of development tools to consolidate information 
from earlier stages of the creation process is taken ad- 
vantage of. The information must not be distributed in 
order not to facilitate the task of an attacker, as is the 
case with any other data used from the final stage of the 
creation process. The modifying is further advanta- 



geously at least partly based on information extracted 
from at least a part of the relocation information, since 
relocation information is in many cases by default auto- 
matically generated by the development tools. Modify- 
ing one or more executable files of the software product 
advantageously eliminates the need for files from a pre- 
vious stage of the compilation process and creates the 
potential for high performance. The modifying compris- 
ing a modification of the arrangement of the subroutines 
and/or variables within the software product provides an 
advantageous means for obfuscating the inner workings 
of the software program. Inserting data and/or code be- 
tween any two subroutines and/or any two variables 
within the software product raises the level of security 
against pirating adversaries in an advantageous imple- 
mentation. Inserting data and/or code into the code of 
one or more subroutines within the software product ad- 
vantageously makes it difficult for an attacker to sepa- 
rate the inserted information from the original code. Ad- 
vantageously, data and/or code is inserted into the soft- 
ware product for testing the integrity of at least a part of 
the software product, to make tampering more difficult. 
In another advantageous implementation, the modifying 
comprises embedding at least a part of a piece of veri- 
fication software, to relieve the developer of the software 
product from the burden of manually and cleverly adding 
verification code. 

[0029] Preferably, the license management software 
program provides means for regulating a distribution 
policy for linking the provision of licenses to a distribu- 
tion scheme. Advantageously, a license is provided by 
uploading it to the license management software. Pref- 
erably, a license is generated by the license manage- 
ment software when its generation is triggered manual- 
ly. Advantageously, a license is generated by the license 
management software automatically when it is needed. 
In a registration procedure each subject accessing the 
license management software program is advanta- 
geously assigned one or more roles, so that subjects 
can be grouped according to their qualities. Uploading 
and/or enabling a generation of licenses is preferably 
only allowed to a subject assigned the role of a software 
supplier, hereby restricting the privilege to create licens- 
es on a need-to-have basis to a limited number of - po- 
tentially identifiable - subjects, since generated licenses 
consume resources of the license server. Initiating a 
provision of licenses preferably comprises defining one 
or more operations on the license to model real-world 
license transactions, whereby further advantageously, 
initiating a provision of licenses comprises linking the 
defined operations or subsets thereof to one or more 
roles such, that each subject enlisted in one or more of 
the roles is capable of performing the operations linked 
to its role or roles, and the operations available to a sub- 
ject advantageously further depend on attributes of the 
subject different from its role or roles to support more 
sophisticated licensing schemes. A subject advanta- 
geously may, depending on the role assigned to it, fur- 
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ther restrict the license conditions of a license, thus e. 
g. allowing a further modification of the set of operations 
of a license available to subjects. The role assignment 
advantageously comprises a separately obtained veri- 
fication of the subject's authorization to enlist in the re- 5 
quested role, like e.g. a verification by an independent 
trust centre to protect the privacy of each licensee, 
whereby further advantageously, the verification of the 
authorization is also or alternatively based on a digital 
signature allowing beneficiaries of an overall contract to 
easily confirm their entitlement. Licenses are advanta- 
geously monitored, whereby each license holds infor- 
mation about the identity of one or more individual down- 
load copies of the software product licensed by this li- 
cense for unequivocal identification. 
[0030] The modification of the copy of the master- 
copy of the software product preferably creates a 
uniquely modified download copy for each download. 
Advantageously, the modification of the copy of the 
master-copy of the software product comprises embed- 
ding information which unambiguously links the individ- 
ual download copy to a subject. The modification advan- 
tageously comprises embedding a unique identification 
of the master-copy of the software product from which 
the individual download copy originates. Preferably, the 
modification comprises embedding a unique identifica- 
tion of the individual download copy. Parts of the indi- 
vidual download copy, which are invariant to the differ- 
ent downloads, e.g. software code of the piece of veri- 
fication software which remains the same for all down- 
loads, can advantageously be kept in one or more files 
apart from the individual download copy so that it can 
be shared between various download copies of different 
applications. 

[0031] Advantageously, the execution control soft- 
ware evaluates licenses matching an individual down- 
load copy on a "best match firsf'-basis, so that if more 
than one license is available for the individual download 
copy, the license restricting the use of further individual 
download copies by an end-user in a minimal way is 
chosen. An approval is preferably transmitted from the 
execution control software program to the individual 
download copy in the form of code and/or data neces- 
sary to obtain a fully usable runtime version of the indi- 
vidual download copy, complicating illicit copying of the 
software product by not providing a fully usable version 
of the individual download copy for persistent storage. 
Advantageously, the approval is a runtime ticket trans- 
mitted from the execution control software program to 
the individual download copy. Hereby, the expression 
ticket generally refers to a kind of message destined to 
handle permissions and which can be examined for its 
authenticity and integrity. Transmitting approval to an in- 
dividual download copy preferably requires successful 
validation of a request ticket supplied by the individual 
download copy. Transmitting approval to an individual 
download copy preferably requires successful valida- 
tion of its integrity. The execution control software pro- 



gram advantageously effects changes to be made to the 
individual download copy and also or alternatively to the 
stored tickets, which can be used to provide a method 
of synchronisation between the individual download 
copy and the license server. Advantageously, the exe- 
cution control software program treats the reception of 
a valid log-off ticket sent from an individual download 
copy as a notification of the termination of the execution 
of this individual download copy, whereby particularly 
advantageously the individual download copy further 
has to prove that its runtime version has been rendered 
unusable before the log-off ticket is being accepted. 
Preferably, the execution control software program 
maintains a log for each license which contains the iden- 
tities of all executing individual download copies that 
have been granted permission to run by the license that 
the log is assigned to, whereby further advantageously 
these logs influence the replies of the execution control 
software program to requests for a permission to run by 
individual download copies. 

[0032] Preferably, an individual download copy is a 
uniquely modified copy of the master-copy of the soft- 
ware product. Advantageously, individually modifying 
the copy of the master copy for download comprises 
adding identifying information to it. Individually modify- 
ing the copy of the master copy for download preferably 
comprises embedding at least a part of a piece of veri- 
fication code for carrying out the steps of querying an 
execution control software program to obtain a permis- 
sion to run at a start-up of the individual download copy, 
and continuing an execution of the individual download 
copy if a permission to run is obtained and aborting the 
execution otherwise. Advantageously, the individual 
download copy notifies the execution control software 
of an infringement of its integrity. When the individual 
download copy queries an execution control software 
program for a permission to run, it advantageously for- 
wards identification data. The identification data advan- 
tageously comprise the identification of the licensee. 
Equally advantageously, the identification data com- 
prise the identification of the master-copy underlying the 
individual download copy. Preferably, the identification 
data comprise the identification of the individual down- 
load copy. 

[0033] A request ticket is preferably supplied with a 
query to obtain a permission to run. Also preferably, a 
runtime ticket received from the execution control soft- 
ware program constitutes that permission to run. Advan- 
tageously, a log-off ticket is received from the execution 
control software program, and further advantageously 
the log-off ticket is returned to the execution control soft- 
ware program at the process of terminating the execu- 
tion of the individual download copy. At least a part of a 
piece of verification code is advantageously embedded 
in one or more subroutines to verify the validity of at least 
one type of ticket for hampering any tricking of the ticket 
mechanism. Each time a subroutine of the individual 
download copy is invoked, a piece of code embedded 
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therein advantageously increments a counter particular 
to the invoked subroutine, whereby further advanta- 
geously, the reading of each of the counters is submitted 
to the execution control software program at the process 
of terminating the execution of the individual download 5 
copy, so that the individual usage of each individual 
download copy can be examined. At least part of a piece 
of meta-verif ication code is preferably embedded in sub- 
routines to verify the integrity of a least a part of the in- 
dividual download copy. A provision of means for an ex- 
ecution of code supplied by the execution control soft- 
ware program advantageously enables the download 
copy to perform special tasks requested by the execu- 
tion control software program, whereby further advan- 
tageously, a provision of means for returning a result of 
the execution of this code to the execution control soft- 
ware program enables the execution control software 
program to evaluate the result of the code execution. 
[0034] A software license management and online 
software license enforcement can e.g. be implemented 
in a client-server-architecture like the world-wide web 
information system in the Internet. In this context, the 
term "server" relates to the general role of a computer 
offering services, while the term "client" refers to the 
general role of a computer requesting services. It has to 
be noted that the present invention is not restricted to 
an implementation in a public network, but is in the same 
manner applicable in an intranet. 
[0035] The software license management and online 
software license enforcement system according to the 
present invention can further be implemented in a busi- 
ness model for providing license services to the soft- 
ware industry, e.g. software suppliers and software mer- 
chants. According to this business model, the services 
offered to a software supplier include an upload of the 
respective software products in addition to an upload of 
corresponding licenses onto the license server, and the 
automatic enforcement of the license regulations by the 
license server. Alternatively, the licenses may be gen- 
erated on the server. A software supplier may hereby 
structure the license provision to his own convenience 
and by this define a distribution scheme according to his 
own choice. Distributors and dealers are provided by 
this model with a lean administration system, reducing 
software distribution to a virtual trading of licenses and 
rendering a real shipment of software on data carrier su- 
perfluous. To an end-user of a piece of software the busi- 
ness model provides the service of an automatic license 
enforcement, which guarantees him juridical security by 
excluding any misuse of an acquired piece of software. 
Furthermore, license terms can easily and at any time 
be adapted to altered requirements on a user's side. To 
protect the identity of an end-user and for separating his 
real identity from the utilisation log of the software he 
employs, an independent trust centre is provided in this 
business model, which handles the validation of the 
roles each subject acquires in the system. 
[0036] In the following description, the present inven- 



tion is explained in more detail in relation to the enclosed 
drawings, in which 

Fig. 1 is a functional scheme of the software license 
management and online software license enforce- 
ment method according to the present invention, 

Fig. 2 shows an example of initiating a provision of 
licenses according to the present invention, where- 
in Fig. 2a is an example for linking operations to 
roles, Fig. 2b is an example for configuring license 
characteristics, Fig. 2c shows an example of a li- 
cense, and Fig. 2d and Fig. 2e show the process of 
license configuration, 

Fig. 3 shows and compares the license and the soft- 
ware transfer according to the present invention, 

Fig. 4 shows a schematic of a typical scenario of 
acquiring a licensed software product, 

Fig. 5 is a block diagram of the license server ac- 
cording to the present invention, 

Fig. 6 shows the main segments of an executable 
file loaded into a memory when the executable is 
. run, 

Fig. 7 shows an example for the individualisation of 
an executable file according to the present inven- 
tion, 

Fig. 8 shows the process of permutating the sub- 
routines of an executable file according to the 
present invention, 

Fig. 9 shows the reconstruction of distributed iden- 
tification data when requesting a permission to run, 
and 

Fig. 1 0 shows one way of inserting a ticket in a data 
segment. 

Fig. 11 shows the ticketing mechanism according to 
the present invention. 

[0037] In the drawings, like elements are assigned 
identical reference numerals. 

[0038] Fig. 1 illustrates the functions and services 
supplied by a license server 1 0 according to the present 
invention to the subjects taking part in the distribution or 
use of a software product. The service offered to soft- 
ware suppliers 11 includes an upload or generation of 
licenses, a transfer of licenses to resellers 12 or end- 
users 13, and an upload of the software product to be 
traded with the method according to the present inven- 
tion. A reseller 12 does not have to sell the software in 
its material form but acquires and transfers licenses to 
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other resellers 12 or end-users 13, while the end-user 
13 downloads the software himself as soon as he has 
acquired a license. It is to be noted that the scheme of 
Fig. 1 does not represent a detailed description of the 
processes involved, but defines the main groups of sub- 5 
jects, and the basic functionality provided by the license 
server for these groups of subjects. 
[0039] Prior to being granted access to the services 
of the license server 10, each subject has to register. 
The registration procedure defines the role or roles of 
each subject taking part in the system and thus assigns 
it its basic privileges. The modes and methods of regis- 
tration can be laid down by the operator of the license 
server 1 0 but additionally also by a software supplier 1 1 . 
Each subject accessing the license server 1 0 for a first 
time, will be transferred to the registration where it en- 
ters ail the information necessary for being assigned a 
membership in one or more of the basic groups of sub- 
jects, i.e. for being assigned its role or roles. For some 
groups a confirmation of the information entered might 
be necessary, whereby the confirmation usually will be 
submitted on a different channel, like e.g. it could be a 
pre-condition for a software supplier to sign a contract 
in a written form before he can enjoy the services pro- 
vided by the license server. For a dealer, submitting a 
copy of his certificate of registration might be necessary 
as a confirmation. Very often, special types of end-users 
for which special conditions are offered have to prove 
their entitlement before they can enjoy the advantages. 
[0040] The examination of the certificates proving an 
entitlement is in the ordinary course of things not as- 
signed to the operator of the license server 10 nor to 
somebody being a member of one of the defined groups 
of subjects, but will usually be handled by independent 
trusted persons or organisations like e.g. a trust centre. 
Under certain circumstances, particularly when student 
certificates have to be certified, even academic book 
shops or academic self-administrating organisations 
might take over the task. By keeping status verification 
separate from the license management system, the full 
and real identity of any subject participating in the sys- 
tem is kept apart from the identifying information stored 
in the license server. 

[0041] If not already prepared by the operator of the 
license server 1 0, a software supplier 1 1 may further re- 
group the resellers 12 and/or end-users 13 for refining 
a given set of roles or adding new roles. Thus, he can 
bring the license management system of the license 
server Into agreement with his very special preferred 
distribution scheme. As an example and with reference 
to the reselling group of subjects, the following roles 
maybe applicable in a hierarchical distribution scheme: 
The role of a distributor 12, reselling software licenses 
to other distributors 12 and/or dealers 12, who in turn 
will resell these software licenses to other dealers 12 
and/or end-users 13. For end-users 13 distinct roles 
may not only be defined for commercial and governmen- 
tal end-users, but also for members of educational or- 



ganisations like a university. Sometimes evaluation cop- 
ies of a software are provided to allow potential end- 
users to test the software for a limited period of time with 
respect to their requirements. When deciding to acquire 
the product later, those prospects only have to apply for 
a different license type. At the time a prospect asks for 
an evaluation copy, usually nobody will be interested in 
his specific role or roles. Practically, prospects may 
therefore be handled as anonymous end-users that do 
not have to provide proof of their identity, until their dis- 
tinct role or roles have to be certified on buying a prod- 
uct. 

[0042] The license server 10 does not necessarily 
have to be a single device as it might be indicated by 
the presentation of Fig. 1 but can just as well be a cluster 
of servers or even a system of distributed servers com- 
municating with each other through a public network or 
an intranet. All subjects participating in the system ac- 
cess the server via a network, in a preferred embodi- 
ment of the present invention through a public network 
like the Internet. Advantageously, on the client side only 
a conventional browser software is needed to access 
the license server according to the present invention. By 
relying on standard software on the client side for ac- 
cessing the server, the effort for maintaining the system 
is reduced considerably. The proposed central system 
and data management further allows dynamic changes 
of distribution models and licensing conditions. 
[0043] A subject being assigned the role of a software 
supplier 11 , is allowed to upload a software for further 
distribution to the license server 10. The software itself 
is not traded, which means that it does not change 
hands in the course of distribution, instead, the right to 
use the software, or to put it another way the license is 
traded between the different subjects. 
[0044] Parallel to uploading the software, a software 
supplier 1 1 has to make sure that subjects can acquire 
titles to use the software. In other words, he has to pro- 
vide licenses for the software. A supplier 11 can either 
upload licenses to the license server 1 0, or he can man- 
ually generate the licenses or configure an automatic 
generation of licenses with the help of the license man- 
agement software program. Since licenses consume re- 
sources of the license server, uploading licenses or set- 
ting up a generation of licenses is a privilege conceded 
to software suppliers only. 

[0045] Generally, subjects will acquire licenses from 
the license server 1 0 and transfer those licenses to other 
subjects. Thereby a license does not literally change 
hands because each license is kept available on the li- 
cense server 10 such, that only the ownership on a li- 
cense is transferred from subject to subject. 
[0046] It is important to understand that a license 
transfer can either be initiated by the transferring party 
or by the receiving party. In this application, the former 
variant is typically implied by "X transfers to Y", whereas 
the latter form of initiation is explicitly stated as "Y ac- 
quires from X". Technically, however, the actual transfer 
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is the same in both cases, i.e. the ownership of a license 
is moved from X to Y. if one of the alternatives is explicitly 
mentioned, then the inverse direction is also possible. 
In both cases, X has to consent to the transaction. 
[0047] When an end-user 13 has acquired a license, 5 
he is allowed to download the respective software from 
the license server 1 0. In the process of downloading the 
download copy is individualised and linked to its respec- 
tive license on the server, so that each individual copy 
of a software file as well as the corresponding license 
can be identified at anytime. When an end-user 13 runs 
the software, the program requests a permission to run 
from the license server 1 0 which in turn checks the per- 
missibility of the request by examining the identity of the 
individualised software and the respective license. If the 
permission is denied, the software terminates itself and 
the user will not be able to run the software. Software 
protection is thus implemented by having the software 
ask the license server 10 for a permission to run each 
time it is being started by an end-user 13. 
[0048] Software suppliers 11 offering software pack- 
ages of a large volume might prefer to offer only a small 
but essential part of the software for download. The ma- 
jor part of the software is then conventionally distributed 
(on a recording medium like a floppy disc or compact 
disc together with additional material like manuals and 
introductory information). When an end-user 13 installs 
the acquired package, the installation routine will re- 
quest to contact the license server to confirm the license 
and download the missing part of the software. 
[0049] Fig. 2 provides an example of how to configure 
the provision of licenses with the license manager ac- 
cording to the present invention. Each license contains 
a license policy and license characteristics, which to- 
gether represent the license conditions of the license. 
In addition, operations are defined for each license, 
such as transferring the license to a subject. The license 
policy concedes the privilege to perform one or more of 
these operations to subjects of different roles. A license 
policy can be described by a matrix of rights, in which 
the columns represent subjects and the rows represent 
operations. 

[0050] On creation of a license, the license type of the 
license to be created is evaluated and selects the li- 
cense policy to be copied to the newly created license. 
[0051] In the example of Fig. 2a, which shows just one 
of an infinite number of distribution schemes configura- 
ble with the system, nine operations are assigned to 
eight different roles within four different license policies, 
i.e. for four different license types ("Educ", "Eval", 
"Comm" and "Deal"), thus forming four matrices of 
rights, each matrix representing a different license pol- 
icy and hence a different license type. 
[0052] In its entirety, Fig. 2a represents a distribution 
scheme by defining the relationship between the avail- 
able operations and the available roles for the different 
license types established for a software product. The 
distribution scheme consists of three dimensions, 



namely the roles, the operations and the license types. 
It has to be noted that any distribution scheme may gen- 
erally be represented by matrices that describe the re- 
lationship between any two of the three dimensions. 
Therefore, the above example could also have been 
represented by e.g. eight matrices for the eight defined 
roles, each matrix specifying the operations allowed for 
one role on licenses of each license type. 
[0053] The eight roles made available herein for the 
distribution of the software product are in detail the soft- 
ware supplier (Pro), who in this context acts as a pro- 
vider of licenses, the distributor (Dis), the dealer (Dea), 
the dealer specialised in educational licenses (Dea-E), 
the commercial end-user (Com), the governmental end- 
user (Gov), the educational end-user (Edu), and finally 
the anonymous end-user (Anon), who is allowed to use 
the software for evaluation purposes only. 
[0054] It has to be understood that, forthesake of sim- 
plicity, in this example the right "Transfer to X" is to be 
interpreted in its technical sense and therefore controls 
both alternatives of initiating the transfer, i.e. the initia- 
tion of the transfer by the receiver X of the license as 
well as the initiation of the transfer to X by the subject 
owning the icense. 

[0055] According to the example of Fig. 2a, only the 
software supplier 11 can provide licenses of any license 
type, i.e. in each matrix the software supplier is the only 
role that is conceded the privilege to perform the "Pro- 
vide" operation. The license policies in general do not 
allow a distributor to sell any licenses to end-users, but 
to other distributors or dealers, thus defining an indirect 
distribution system. As can also be seen, a differentia- 
tion is made between a regular dealer and a dealer for 
educational licenses such, that the former is not allowed 
to trade - i.e. neither acquire or transferlicenses of type 
"Educ" and the latter is not allowed to trade licenses of 
type "Comm". However, both may distribute evaluation 
licenses (type "Eval"), acquire dealer licenses (type 
"Deal") and pass them to other dealers. Enforcing re- 
strictions according to the scheme described facilitates 
the control of distribution channels. 
[0056] Moreover, the example illustrates that the term 
"end-users" refers to subjects that enjoy the privilege of 
performing the "Use" operation, i.e. that may actually 
use the licensed software product. 
[0057] Reflecting a discount system, different types of 
end-users are defined in the given example. The most 
expensive license is generally the commercial license 
for a commercial end-user, while usually governmental 
organisations get discounts in the form of a governmen- 
tal license. Although the role of a governmental end-us- 
ers exists in the above example, the software supplier 
11 chose not to create a separate license type for gov- 
ernmental end-users. In this case, also governmental 
organisations have to pay the full price of a commercial 
license. 

[0058] The budget of educational institutions like e.g. 
universities is very often in blatant discrepancy to their 
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need for sophisticated technical equipment. Therefore 
it is common practice that the price for an educational 
license is only a fraction of the price for commercial end- 
users and even lower than the price for a governmental 
version. A software supplier hereby calculates on the 5 
fact that a student working in an educational institution 
prefers to continue his or her work with the software he 
or she feels already comfortable with when later worki ng 
in the industry. To reduce the cost for distribution of ed- 
ucational software a fixed price is occasionally agreed 
to with a government of a state, so that members of a 
university of that state further only have to prove them- 
selves being beneficiaries of the treaty to get a license 
"for free". Students, generally considered as being po- 
tentially broke are usually eligible for educational licens- 
es and therefore classified as educational end-users, 
too. Still, technically also educational institutions and 
students have the right to buy a more expensive com- 
mercial license. 

[0059] Finally, also dealers get special conditions for 
dealer licenses, which they use for marketing purposes, 
like presentations to prospects. In this case, also deal- 
ers become end-users. 

[0060] Sometimes a prospect is given the opportunity 
of acquiring an evaluation license and use a software 
product for a limited period of time in which he is allowed 
to evaluate the usefulness of the software with respect 
to his requirements. Typically, in this situation the status 
of the end-user is not relevant. Hence the role of the 
anonymous end-user "Anon", in which subjects can en- 
list without having to prove their identity. 
[0061] Restricting the operations available to a sub- 
ject to exactly those operations that are linked to its role 
or at least one of its roles guarantees that each subject 
is only conceded the privileges proper for its role or 
roles. A commercial end-user will e.g. be unable to ac- 
quire a cheaper educational license and it will be equally 
impossible for a dealer to sell and/or transfer an educa- 
tional license to a commercial end-user. 
[0062] The matrices of Fig. 2a further model the com- 
mon practice of transferring the ownership of a license 
from one subject to another. In the indirect sales scheme 
reflected in the table, distributors can only transfer li- 
censes to other distributors or dealers, whereas dealers 
are entitled to transfer the acquired licenses to either 
their peers or end-users. According to the example a 
dealer specialised in educational licenses may sell ed- 
ucational licenses only to educational end-users or oth- 
er educational dealers. 

[0063] An end-user will typically have to register with 
the license server and then ask a dealer to transfer an 
appropriate license to him. 

[0064] Sometimes, like in the course of selling a cer- 
tain business division also end-users will be allowed to 
transfer the ownership of their licenses to a new bene- 
ficiary, who in this special example occupies a role for 
which higher or equal discounts are offered. The restric- 
tion is important in order to e.g. prevent a student from 



acquiring an educational license and then passing it to 
a commercial end-user. 

[0065] In modern distribution schemes, the discounts 
given do not only depend on the roles assigned to the 
licensees, but also on the number of licenses ordered 
and/or on the number of licenses already owned, i.e. on 
attributes of a subject that are different from its role or 
roles. Still, these cases can easily be modelled within 
the presented paradigm by supplying a mechanism for 
ad hoc roles, i.e. additional roles that are temporarily 
assigned by the license management system to a sub- 
ject while a matrix of rights is evaluated. If an ad hoc 
role "Subject owning an upgradeable license of Word 
Processor 1.0" existed, which was automatically as- 
signed to each subject owning an upgradeable license 
for "Word Processor 1.0", a license policy enabling an 
upgrade from "Word Processor 1 .0" to "Word Processor 
2.0" could be created such, that licenses of this class 
would only be transferable to subjects already owning 
an upgradeable license of "Word Processor 1.0", i.e. 
subjects being assigned the ad hoc role of "Subject own- 
ing an upgradeable license of Word Processor 1.0". 
Therefore, to bias the end-user's decision for buying the 
new product from the same software supplier from 
whom he got the current one, a special discount can be 
given on the price of the new license depending on the 
currently used license. This is also applicable, when an 
end-user owns one or more software programs from one 
software supplier and orders additional software pro- 
grams of any kind from the same supplier. 
[0066] Further, the license scheme may include float- 
ing licenses or even floating licenses for an assortment 
of different software products typically from the very 
same software supplier. Hereby the term "floating li- 
cense" means, that a user installs the software product 
several times on different computers, whereby the li- 
cense server just ensures that the total number of simul- 
taneously used copies does not exceed the number of 
licenses bought. The term "assortment license" repre- 
sents a license that allows an end-user to acquire sev- 
eral distinct software products, typically from one and 
the same supplier, a so-called assortment, from which 
he can use a certain number of products concurrently. 
[0067] Therefore the characteristics of the licenses 
available within the licensing scheme have to be defined 
by the software supplier. The software supplier does so 
by creating a license class - i.e. a prototype - for each 
variant of licenses to be provided. 
[0068] A license class consists of the license charac- 
teristics as well as the license type to be used for crea- 
tion of licenses of said license class. An example thereof 
is given in the table of Fig. 2b, wherein the available li- 
cense classes ("EDU-1", "EDU-2", "EVA-1", "COM-1", 
"COM-2" and "DEA-I") for assortment licenses for an 
office suite consisting of "Word Processor 1 .0", "Spread- 
sheet 1 .0" and "Database 1 .0" are defined. Further char- 
acteristics cover the period and the number of times for 
which the licensed product can be used. 
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[0069] If a software supplier triggers the creation of a 
"COM-1" license, the corresponding license class will 
be looked up, the license characteristics will be copied 
from the license class to the newly created license, the 
license type in the specified license class ("Comm") will 5 
be looked up and the license policy corresponding to the 
license type will also be copied to the newly created li- 
cense. 

[0070] According to the given example of Fig. 2b two 
classes of "Educ"-type assortment licenses are availa- 
ble for one or 50 simultaneous users. In the latter case 
the lifetime of the licenses is limited to 5 years. For eval- 
uation purposes, a class of "Eval"-type licenses is de- 
fined, which will expire after 30 days or 50 program in- 
vocations, depending on what condition will be met first. 
The validity of the class of "Dear-type licenses is limited 
to one year. Further, three different classes of "Comm"- 
type licenses exist, each license class having a limited 
lifetime of 5 years and limiting the number of concurrent 
users to 10, 50 or not at all. 

[0071] An example of a license created for an educa- 
tional end-user is given in Fig. 2c, granting a floating 
license for 50 concurrent uses of any combination of 
software products from the assortment containing 
"Word Processor 1.0", "Spreadsheet 1.0", and "Data- 
base 1 .0". According to the license type and the corre- 
sponding license policy, educational end-users are al- 
lowed to use the software, and can further transfer it to 
another educational end-user if he desires to do so. He 
can use the program as often as he likes, but the license 
expires five years after its acquisition in March 2001 . 
[0072] Instead of triggering license creation manually, 
the supplier may prefer to establish a set of rules to en- 
able the license server to automatically generate and 
transfer licenses of certain classes in response to at- 
tempts to acquire a license of an appropriate class, if 
specified pre-conditions are met. The same mechanism 
can be used for transfer-only transactions, e.g. from a 
dealer to an end-user. In this example, the pre-condition 
would typically be the payment of the corresponding li- 
cense fee by the end-user to the dealer. In most cases, 
the fulfilment of the pre-conditions will be verified by ex- 
ternal means and then communicated to the license 
server. 

[0073] In addition, it is obvious to those skilled in the 
art of computer programming, that performing the divi- 
sion of licenses into parts differently from the presented 
method, i.e. into pieces different from license policy and 
license characteristics, can beconceived. Moreover, the 
described license characteristics, operations and roles 
are only examples chosen for illustration. It is obvious 
that extensions to the described characteristics, e.g. a 
limit on the total number of program installations or role- 
dependent license characteristics can be realised. 
[0074] By definition, operations on a license may in- 
clude modifying the license policy or license character- 
istics, which are copied to a license on creation and thus 
part of it, such as conceding to or revoking from selected 



roles the right to perform certain operations on the li- 
cense. However, care should be taken when designing 
a license policy to ensure that subjects cannot relax but 
may only tighten the restrictions imposed on a license 
by the license policy and the license characteristics. 
This typically means that subjects will only be allowed 
to e.g. revoke privileges from roles, i.e. to further restrict 
the license conditions. 

[0075] It is further important to note that said modifi- 
cations are carried out on the copy of the license policy 
or license characteristics local to a license and thus only 
affect the license of which the modified policy or char- 
acteristics are a part. 

[0076] It is to be understood, that the example given 
in Fig. 2a, 2b and 2c is just an illustration of the general 
working of the present invention and that only features 
relevant for the understanding of it are shown. 
[0077] Each subject accessing the license server 10 
for the first time has to apply for one or more roles. For 
some roles the status of the subject has to be confirmed 
separately, e.g. a distributor may be asked to send proof 
of his professional status. Very often, established distri- 
bution channels already exist sothatthe distributors and 
dealers are already known to the software supplier 11 . 
A software supplier may then upload a list of distributors 
and dealers authorised to acquire licenses. In this case 
the information supplied by the distributor or dealer will 
only be cross-checked with the information provided by 
the software supplier 11. If the applicant can be found 
in the list provided by the software supplier 11 , the ap- 
plicant will be assigned the appropriate role or roles. If 
not, the applicant will be referred to the software supplier 
11 to obtain authorisation. 

[0078] In Fig. 2d the registration process for subjects 
applying to use the service of the license server 10 is 
illustrated in a flow chart. If a subject desires to obtain 
membership in more than one role, the process is re- 
peated for every role. 

[0079] In an indirect sales scheme, an end-user asks 
a dealer for a license of a software product. The dealer 
will either own or order an appropriate license. As soon 
as the end-user 13 is registered on the license server 
1 0, the dealer will transfer the license to him. Dependent 
on one or more of the roles of the end-user 1 3 the license 
server 1 0 will ask for a separate confirmation of an end- 
user's special status, e.g. a proof of him being member 
of a governmental or educational organisation or him 
being a student. The confirmation will usually be han- 
dled via a third party like a separate trust centre. 
[0080] The acquisition of licenses can be organised 
in various ways. The simplest way is that the software 
supplier uploads a bundle of single licenses to the li- 
cense server 10 which are transferred via resellers 12 
to end-users 13. It has to be noted, that a transfer of 
licenses is not a real transfer of something physical like 
a sheet of paper or a file, but is simply a transfer of the 
ownership of the license. The license itself, i.e. the in- 
formation about the conditions for the use of the related 
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software product, is kept on the license server all the 
time. 

[0081 ] Usu ally, the means of the license management 
system for either manually or automatically generating 
licenses on the basis of a configuration provided by a $ 
software supplier according to a scheme as exemplary 
illustrated in Fig. 2a to Fig. 2c will be used, the pre-con- 
dition for an automatic generation typically being the 
payment of the license fee. 

[0082] A license will not only be linked to its actual 
owner, but also to the information who acquired it during 
its journey from the supplier to the end-user, i.e. the li- 
cense is also linked to the identities of e.g. the distribu- 
tors and dealers involved in the acquisition process in 
addition to the identity of the end-user. This allows easy 
and effective automatic accounting that extracts the rel- 
evant information directly from the license server. 
[0083] The flow chart of Fig. 2e shows the basic steps 
to betaken by a software supplier to configure the gen- 
eration of software licenses for a certain piece of soft- 
ware. Hereby it is presumed that the link of the license 
configuration to the respective identity of the licensed 
software product is already established. In the first step 
S1 a software supplier selects the roles of the subjects 
allowed to take part in the distribution process. In case 
the roles provided by the license management system 
do not cover the roles necessary for setting up a licens- 
ing scheme according to his distribution requirements, 
a software supplier may define roles on his own. These 
roles can be made publicly available in agreement with 
the operator of the license server 10. New roles can 
hereby also constitute a certain specialisation of a gen- 
eral role, like e.g. a new role of a dealer specialising in 
sales to educational end-users (Dea-E) is defined as a 
dealer (Dea) with only educational end-users (Edu) al- 
lowed as customers. This mechanism is similar to the 
inheritance mechanism known from object-oriented lan- 
guages. Additionally, in step S2 the roles can be classi- 
fied to define for which roles the applicant has to prove 
his entitlement together with the respective proof meth- 
od. In step S3 a software supplier selects the operations 
he needs to set up his distribution scheme. In step S4 
he creates license policies and thus configures the al- 
lowance to perform an operation for each of the selected 
roles for each license type separately as shown in Fig. 
2a. In step S5 license characteristics are selected as 
described in Fig. 2b and in step S6 the license charac- 
teristics and license types are combined to form license 
classes as outlined in Fig. 2c. 
[0084] The example chosen shows the capacity of the 
license management software for designing licenses 
and a control of the transfer of these licenses for very 
different distribution schemes and for mapping even 
very sophisticated distribution structures herewith. But 
also very simple models can be established with the 
means for providing licenses within the license manage- 
ment system. To reproduce a shareware sales structure, 
a software supplier defines, except for his own role, only 



the role of an end-user, e.g. the anonymous end-user 
"Anon". An end-user now is allowed to register with the 
system without separate proof of his identity. After com- 
pleting registration and acquiring an evaluation license 
valid for a limited time, the end-user can download a 
copy of the software product. If an end-user decides to 
buy the program, he will do so by acquiring a full license, 
which he will get after payment of the due license fee. 
Payment can be accomplished using the usual payment 
methods established in the Internet. The end-user does 
not, however, have to download a new copy of the soft- 
ware. If the end-user decides that he prefers not to buy 
the software, the software will cease to work after the 
evaluation license has expired. 
[0085] Fig. 3 illustrates the principal processes in- 
volved in a license management according to a special 
embodiment of the present invention. It demonstrates 
that the transfer of licenses is a virtual transfer, wherein 
no items are passed from one to another but rather a 
title on a license is transferred from one subject to an- 
other. E.g. a supplier 11 creates licenses on the license 
server according to one of the methods described above 
and the license or better the title to the license is trans- 
ferred 31 to a reseller 1 2 on the occasion that a reseller 
12 acquires the license. The right on the license is fur- 
ther on transferred 32 to the end-user 13. In contrary 
hereto, the software is transferred 33 directly from the 
supplier 11 who uploaded it to the license server 10 to 
the end-user 13 who downloads the software from the 
license server 10. This is a real transfer because the 
end-user 13 receives the software in the form of files on 
his hard disc. 

[0086] The whole system according to the present in- 
vention will be described by means of an example of a 
typical scenario 40 according to Fig. 4. It is assumed 
that the subjects of the scenario, a software supplier 11 
(S), a reseller 12 (R), and an employee of a company 
13a (C) are already registered with the license server. 
An employee of a university 13b (U) has to prove during 
the registration process, that he or she actually repre- 
sents a real university and is thus eligible for educational 
licenses. To make sure, that the full identity of the end- 
user is kept separate from his licensing data on the li- 
cense server and also that the use of an individual li- 
cense cannot be linked with the real identity of a licen- 
see, a trust centre takes over the verification of a user's 
role if required. A trust centre confirms the data neces- 
sary for the registration process, but is usually not able 
to inspect the licensing information. 
[0087] The first process initiated is the transfer of li- 
censes. S uploads to the license server a piece of soft- 
ware for distribution by the license server. This makes 
S the supplier of this piece of software. Only the supplier 
of a piece of software will be authorised to generate li- 
censes for that software. The reseller R notices that the 
piece of software is now available and asks S for, say, 
ten educational licenses. S - or more likely, the license 
management software - generates ten educational II- 
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censes and transfers them to R. U asks R for an edu- 
cational license for the piece of software. If U is regis- 
tered as an educational institution, R is able to transfer 
the license to him. However, R would not be able to 
transfer one of the educational licenses to C, since C is 5 
not registered as an educational institution. Even if R 
were able to transfer an educational license to C, C 
would not be able to run the software, as will be de- 
scribed below. U now owns an educational license for 
that piece of software. 

[0088] Next, the actual software is transferred by U 
downloading the piece of software from the license serv- 
er. During the download, this particular download copy 
is fingerprinted with an individual watermark and thus 
linked to U. In addition verification code is added to the 
software. Further, information about the applied individ- 
ual watermark is linked to the license owned by U, thus 
linking the license to this particular download copy. 
[0089] Next, when U runs the piece of software, it asks 
the license server for permission to run. The license 
server looks up the licenses held by U, discovers that U 
owns an educational license, verifies that U is an edu- 
cational end-user and grants permission to run. As- 
sumed C tried to run the piece of software, the license 
server would then deny permission to run even if R had 
managed to transfer an educational license to C, be- 
cause C is not registered as an educational end-user. 
[0090] As can be easily seen from this example, the 
actual piece of software is only transferred from the li- 
cense server to the end-user. Transactions between the 
software supplier and the resellers or among the resel- 
lers are restricted to a transfer of licenses only. More 
precisely, the license server transfers an ownership on 
a license just by keeping log of who owns which license 
or licenses, respectively. 

[0091] Fig. 5 shows the software components of the 
license server 10 which in their interaction provide the 
method for the license management and online license 
enforcement according to the present invention. The 
registration control software 51 handles the process of 
assigning one or more roles to each subject participating 
in the system. Only subjects registered are allowed to 
access the license management software 52 which e.g. 
provides the means that a software supplier can upload 
his piece of software and provide licenses of the desired 
license classes or that licenses can be transferred. In- 
formation about each registered subject is stored in the 
user database 58. The pieces of software from the soft- 
ware supplier are kept on stock in the program storage 
53. The licenses uploaded or the configuration data for 
the manual or automatic generation of licenses, respec- 
tively, are held available in the license storage 54 of the 
license server 10. 

[0092] The download control software 56 checks the 
license data of the licensee and fingerprints a copy of 
the master-executable file of the piece of software, 
which the software supplier uploaded before, according 
to the license information read out from the license stor- 



age 54. The fingerprint data are stored in the fingerprint 
data storage 57. In addition, the license corresponding 
to the download is linked to the downloaded copy of the 
piece of software by adding a reference to the fingerprint 
data in the fingerprint data storage 57 to the license in 
the license storage 54. The actual license enforcement 
is carried out by the execution control software 55. The 
execution control software 55 receives the requests for 
a permission to run from the individual downloaded piec- 
es of software via a network and determines with the 
information obtained along with the request and the in- 
formation of the respective license stored in the license 
storage 54, whether to grant the permission to run. In 
case of a positive decision, it does so by sending ap- 
proving information to the software which has posted the 
request. According to a preferred embodiment of the 
present invention, the execution control software 55 fur- 
ther exchanges data with the applying piece of software 
to check the integrity of the software copy itself and of 
the information obtained from it. 
[0093] The download control software 56 provides an 
individual download copy by individually modifying a 
copy of the master-copy of the requested software prod- 
uct for being downloaded from the license server. The 
individualisation of the download copy comprises finger- 
printing the download copy and adding verification code 
to it. In the fingerprinting process a software watermark 
is added transparently to the download copy, whereby 
transparently means, that the watermark is information 
embedded invisibly to a user. The individual software 
watermark links the individual copy to the subject down- 
loading it. The responsibility of the verification code is 
to ensure that the software can only be used if the sub- 
ject owns a corresponding license, that the software 
code has not been tampered with, and that correct in- 
formation is exchanged with the correct license server 
10. 

[0094] When software is developed, this is typically 
done in a high-level programming language like e.g. C, 
C++ or PASCAL. The material result of the programming 
is a source code file, typically an ASCII-file of more or 
less cryptic representation. In generating an executable 
file from the source code of the software the following 
intermediate steps are involved, which are often hidden 
from the programmer by an integrated development en- 
vironment (IDE). By compiling, the source code files are 
translated from the high-level language into equivalent 
assembly language source code files. This is typically 
done by translating each function (procedure, method, 
etc.) of a source code file from the high-level language 
into an equivalent assembly language subroutine and 
writing the result to the corresponding assembly lan- 
guage source code file. Furthermore, for each variable 
definition an instruction is emitted to the assembly lan- 
guage source code file which reserves storage space 
for the variable and which specifies the initial value of 
the variable. In addition, a unique label is assigned to 
the storage space of the variable. This label is used to 
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refer to the storage space of the variable, e.g. by an as- 
sembly language instruction that modifies the value of 
the variable. Further, a unique label is assigned to the 
first instruction, i.e. the entry point, of each subroutine 
which is used to refer to the subroutine, e.g. by an as- 5 
sembly language instruction that invokes the subrou- 
tine. 

[0095] In the resulting file, storage space for subrou- 
tines and variables is therefore generally referenced by 
labels and not by addresses. Labels will only be mapped 
to addresses in the last step of the creation of an exe- 
cutable file. 

[0096] In the course of assembling, each assembly 
language source code file is translated into a sequence 
of bytes that represents the machine language equiva- 
lent of the assembly language source code. These byte 
sequences are stored in object files. 
[0097] In contrast to executable files, subroutines and 
variables are at this stage still linked to their labels and 
the storage space of each subroutine and each variable 
is still referenced by its label. In addition, machine lan- 
guage instructions or locations in the data segment, for 
instance variables that reference a subroutine or varia- 
ble are marked. These are the two major differences be- 
tween object files and executable files. In all other re- 
spects the byte sequences in the object files are already 
very similar to the byte sequences found in the code 
segment of the executable file generated from the object 
files. 

[0098] On linking, all object files are combined into a 
single executable file. Each subroutine is assigned indi- 
vidual storage space in the code segment of the execut- 
able file to provide room for the byte sequence repre- 
senting the subroutine. In addition, the byte sequences 
are copied to the appropriate locations in the code seg- 
ment of the executable file. 

[0099] Further, each defined variable is assigned in- 
dividual storage space in the data segment of the exe- 
cutable file. In addition, the initial values for all initialised 
variables are written to the appropriate locations in the 
data segment of the executable file. 
[01 00] Fig. 6 shows the basic components of an exe- 
cutable file, the code segment and the data segment. 
When loaded into the memory of a computer the code 
segment and the data segment are stored at different 
locations, whereby both segments may be separated by 
memory address space not used by this executable file. 
[01 01] The code segment represents the instructions 
that a piece of software consists of, i.e. it contains a rep- 
resentation of the employed algorithms in machine lan- 
guage form, which can be directly run by a microproc- 
essor. Typically the code segment consists of subrou- 
tines, which are the direct machine language equivalent 
to functions, procedures, methods or similar constructs 
that a high-level programming language offers. Each 
subroutine implements a subset of the total functionality 
of the software and may invoke other subroutines. 
[0102] The data segment stores the data that the in- 



structions in the code segment operate on, i.e. it con- 
tains storage space for each variable used by the imple- 
mented algorithms. 

[0103] In the process of linking the object files to a 
combined executable file a linker replaces all references 
to subroutines and variables by the actual addresses of 
the subroutines and variables, in other words it resolves 
the references. It can do so very easily, because all lo- 
cations that reference subroutines or variables are 
marked in the object files as stated above. On demand, 
the linker also produces a map file, which lists the map- 
pings of all subroutines and variables to their respective 
addresses. 

[0104] At this point the layout of the code segment as 
well as the layout of the data segment is determined. 
The storage space for each variable and each subrou- 
tine is now located at a fixed address. Subroutines and 
variables can now be referenced by their respective ad- 
dresses, which is the only way of referencing storage 
space that is supported by typical CPUs. 
[0105] It is important to note that while moving forward 
from the initial representation of the software program 
towards the executable version of the software program 
as described above, much of the information about the 
software program which is not needed to execute the 
corresponding executable file, e.g. information about 
the exact layout of the data segment, is lost. 
[0106] The basic principle behind fingerprinting ac- 
cording to the present invention is to link to a licensee 
a unique executable file derived from a master-execut- 
able file by changing the layout of the executable file 
and/or inserting identification data specific to each licen- 
see into the code and/or the data segment of the exe- 
cutable file. 

[0107] In addition, further obfuscation techniques 
may be applied to discourage attacks based on compar- 
ing two differently fingerprinted files, e.g. exchanging an 
instruction and its predecessor, if it does not depend on 
the result provided by its predecessor. In general, trans- 
formations modifying the software program but preserv- 
ing its semantics are employed. 
[0108] An example is shown in Fig. 7. The original 
master executable file is composed of a code segment 
comprising subroutine 1 to subroutine 3 and a data seg- 
ment with the variables 1 to 3. In a first step the layout 
of the executable file is altered by pseudo-randomly per- 
muting a sequence of subroutines in the code segment 
and further inserting arbitrary data at pseudo-randomly 
chosen locations between any two subroutines or vari- 
ables. In a second step the variables of the data seg- 
ment are permuted and further additional arbitrary data 
are inserted into the data segment at pseudo-randomly 
chosen locations between any two variables. In the last 
step identification data specific to the licensee are in- 
serted into both segments of the executable file. In the 
example of Fig. 7 the identification data are a sequence 
of bytes representing the word "John". The identification 
data is split up into several sub-units like e.g. into the 
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letters forming the word John and each of the sub-units 
is inserted at pseudo-randomly selected locations be- 
tween any two subroutines or variables of the executa- 
ble file. 

[0109] In order to find the inserted data when exam- 
ining a fingerprinted file, methods are known to those 
skilled in the art of watermarking that do not require 
knowledge of the locations of the inserted data, e.g. im- 
plicitly addressing the inserted data or secretly marking 
the locations of the inserted data. 
[0110] To further increase the robustness of the ap- 
plied watermark, in a special embodiment of the present 
invention additional functionality - i.e. additional code - 
is embedded into existing subroutines. The task of this 
functionality is to make sure that the identification data 
has not been tampered with. E.g. checksums may be 
used to verify the integrity of the identification data. An- 
other possibility is to store the same byte of identification 
data multiple times at different addresses. The addition- 
al code then checks whether the identification data 
stored at a first address contain the same data as the 
identification data stored at a second address. If the data 
are not found to be identical, program execution may be 
hampered or the license server will be informed that the 
download copy has been tampered with. 
[01 11] It has to be noted that the expression "embed- 
ding code" typically implies that at least part of the data 
that the embedded code operates on is also embedded 
or that storage space for data stored by the embedded 
code is created. 

[01 1 2] Software suppliers very often hesitate or to be 
more precise refuse to disclose the source code or to 
make the object code files of their software available. 
Therefore in many cases fingerprinting and the insertion 
of verification code has to be carried out on executable 
files exclusively. In addition, modifying an executable file 
is considerably faster than linking, which would have to 
be done if the fingerprinting was done on the basis of 
object files. However, since information is lost during the 
process of generating the executable file, e.g. referenc- 
es are not marked in executable files, it is difficult to dis- 
cover all references and thus generate a modified but 
still working executable file. 

[01 1 3] Therefore, to be able to perform modifications 
such as the modifications described above, information 
from one or more earlier stages in the generation of the 
executable file, i.e. a stage in which the necessary in- 
formation is still available, has to be extracted. In par- 
ticular, the linker could also produce a map file, from 
which the mappings of all subroutines and variables to 
their respective addresses could be determined. In ad- 
dition, information about the marked locations in the ob- 
ject files that reference variables or subroutines could 
be extracted from the object files. The length of variables 
could typically be determined by examining the corre- 
sponding object or source code files. 
[0114] Since the described loss of information also 
impedes the debugging of an executable file, most soft- 



ware development tools provide the option of extracting 
information about the layout of the code and data seg- 
ment, variable names, variable types, the line number 
of the line in the source code file that corresponds to a 

5 certain memory address of the code segment, etc., and 
store the information in debug information files along 
with the executable file to facilitate the debugging of the 
executable file. So, the necessary information for per- 
forming the modifications can also be automatically 

10 propagated to a final stage of the generation of the ex- 
ecutable file - if supported by the employed software de- 
velopment tools - and be extracted from that stage, e.g. 
from the debug information. Since the information is a 
valuable aid in reverse engineering and analysing an ex- 

15 ecutable file, it is typically not distributed with the exe- 
cutable file, although it is a part of the final stage of ex- 
ecutable file generation. 

[0115] In addition, the debug information may be em- 
bedded in the executable file instead of being stored in 

20 a separate file. However, before distribution, this infor- 
mation is typically removed from the executable file. 
[0116] Moreover, some executable file formats pro- 
vide means for storing relocation information. Reloca- 
tion information consists of a list of ail memory referenc- 
es es in the code segment or data segment of the execut- 
able file. As stated above, references are resolved and 
memory addresses are assigned at link time. Yet, know- 
ing all memory references, the code segment and data 
segment can be loaded and stored in memory starting 

30 at arbitrarily selected base addresses, be adapted to the 
selected base addresses by adjusting all memory refer- 
ences accordingly, and finally be successfully executed 
in the chosen memory area, independent from the ad- 
dresses chosen at link time. Extraction of information 

35 concerning memory references from the relocation in- 
formation is therefore also possible. 
[01 17] In the canonical implementation, the extracted 
information is transmitted to the license server along 
with the executablef ile in the form of a simple ASCI I file. 

40 it contains the information of the address of the begin- 
ning of each subroutine in the code segment and the 
start address of each variable in the data segment. If the 
length of the subroutines and variables are not supplied, 
they can be calculated by the differences of the starting 

45 addresses of two adjacent subroutines orvariables. The 
information about the marked locations contains a list of 
all references from the code segment to any of the sub- 
routines as e.g. generated by subroutine calls or jump 
tables, and to any of the variables as e.g. generated by 

50 parts of the code that accesses a variable. It further con- 
tains a list of all references from the data segment to 
any of the subroutines as e.g. generated by pointer var- 
iables that point to a subroutine and to any of the vari- 
ables as e.g. generated by pointer variables that point 

55 to a variable. 

[0118] The information about the marked locations 
and the layout of the code segment and data segment 
meet the necessary requirements to apply complex 
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modifications to the master executable file and insert in- 
formation into the code or data segment. In addition, the 
information is helpful in analysing the code forming each 
subroutine as well as the relationship between subrou- 
tines. 

[01 1 9] It is to be understood that the information men- 
tioned above is just a simple example of the information 
being transmitted to the license server. In a real-world 
application, different or additional information about the 
executable file may be transferred. 
[01 20] An example of a permutation of subroutines by 
an algorithm according to a preferred embodiment of the 
present invention is shown in Fig. 8. At first, two ran- 
domly chosen subroutines S1 and S2, located at the ad- 
dresses al and a2 with a respective length of 11 and 12 
- i.e. "ell-one and ell-two" and not "eleven and twelve" - 
are selected. Next, the subroutines are saved by for in- 
stance saving 11 bytes starting with the address al and 
saving 1 2 bytes starting from the address a2. In the spe- 
cial case that the length of both subroutines is equal, the 
saved subroutine S1 is stored beginning with address 
a2 and the saved subroutine S2 is stored beginning with 
the address al. To swap the subroutines when the 
lengths differ, the block of subroutines separating the 
two is shifted towards the address of the longer subrou- 
tine. Assumed that the length 11 of subroutine S1 is 
shorter than the length 12 of the subroutine S2 and fur- 
ther that originally subroutine S1 is located at a higher 
address al than subroutine S2 then the block of subrou- 
tines separating S1 and S2 is moved upwards (with re- 
spect to the representation of Fig. 8) into the direction 
of the lower address a2 by 12-11 bytes. The saved sub- 
routine S1 is then stored beginning with the address a2 
and subroutine S2 is stored beginning with the address 
a1-(12-11). 

[0121] In case subroutine S2 is stored at a higher ad- 
dress than subroutine S1 , the block of subroutines sep- 
arating the two is shifted downwards (with respect to the 
representation of Fig. 8) into the direction of the higher 
address by 12-11 bytes. Subroutine S1 is then stored 
beginning with the address a2+(12-11) and subroutine 
S2 beginning with address al. 

[0122] Assumed subroutine S1 is longer than subrou- 
tine S2, then the procedure is in principle the same with 
the only difference that the subroutines separating the 
selected ones are just shifted the other way around. E. 
g. if subroutine S1 is stored at a lower address al than 
subroutine S2, the block of subroutines between the two 
to be permutated is shifted upwards to a lower address 
by a value of 1 1 -1 2 bytes, and in case the subroutine S1 
is stored at a higher address than subroutine S2, then 
the block of subroutines separating the two has to be 
shifted downwards to a higher address by 11-12 bytes. 
In the first case, S1 will then be stored beginning with 
the address a2-(1 1 -1 2) and subroutine S2 will be placed 
beginning with address al. In the second case S2 will be 
stored at the address a1 +(1 1 -1 2) and S1 at the address 
a2. 



[0123] The permutation of the variables in the data 
segment is performed in exactly the same way. By per- 
mutating the subroutines and the variables, the refer- 
ences to and from the subroutines and variables'^ 

5 longer continue to be correct. Therefore, the permuta- 
tion algorithm has to adjust all references to the new 
order in the sequence of subroutines and variables. It 
can do so very easily, since it is in possession of e.g. 
the information about the locations marked in the object 

10 files. 

[0124] Like mentioned above, fingerprinting the exe- 
cutable file can also include the insertion of data be- 
tween any two variables and/or subroutines. To embed 
a sequence of a number of bytes, the algorithm pro- 
's ceeds according to the following scheme. A subroutine 
or variable after which one or more bytes of the se- 
quence will be inserted, is picked out randomly. All sub- 
routines or variables, respectively, located at higher ad- 
dresses than the selected one are then moved towards 

20 higher addresses by the number of bytes to be inserted. 
This creates a gap behind the chosen subroutine or var- 
iable comprising an appropriate number of bytes. Next, 
all references concerned are readjusted. Again, this can 
be accomplished, because e.g. the information about 

25 the marked locations is known from the object files. At 
last, the chosen bytes of data are copied into the gap 
created previously. This procedural sequence is repeat- 
ed until all bytes of the sequence of bytes are stored 
within the executable file. * 

30 [01 25] To covertly verify the integrity of the embedded 
information, and thereby improving the ruggedness of 
the fingerprint against attacks by a malicious subject, 
pieces of code are inserted into several subroutines that 
verify the integrity of the embedded information. Accord- 

35 ing to one preferred embodiment, checksum data are 
added to the information to be embedded and the em- 
bedded code then calculates the checksum of the em- 
bedded information and compares it with the embedded 
checksum data. 

40 [0126] Alternatively or additionally, parts of the em- 
bedded information are embedded redundantly multiple 
times at different locations. The code embedded in a 
subroutine will then load one of the redundant values 
and compare it with the value from a different location 

45 and so on, until the identity of the redundant information 
from the different locations has been verified. If a mis- 
match is found, the program may be made to loop for- 
ever or crash. Especially in this case, it is made very 
hard for an attacker to control the success of his "crack- 

50 ing" efforts. The code will only run, when the subroutine 
it is embedded in is invoked by a program function. As- 
sumed, that a malicious subject misses only one of the 
pieces of information, then the program will run on the 
first try but when it calls a certain function which involves 

55 the subroutine with the embedded code, the program 
will freeze or crash. To be successful, an attacker would 
have to find ail checksums and all instances of the em- 
bedded information for being able to outsmart the em- 
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bedded code. 

[01 27] As a result of inserting code, the corresponding 
subroutine grows in size. Therefore the layout of the 
code segment has to be changed. Assumed, that an ex- 
isting subroutine S3 located at the address a3 will re- 5 
ceive verification code of one of the above discussed 
kinds. First, the extra number N of bytes needed is cal- 
culated, whereby N represents the length of the ma- 
chine language instructions of that verification code. All 
subroutines located at higher addresses than a3 are 
then moved towards higher addresses by N bytes. Sub- 
sequently, the modified version S3* of S3 containing the 
additional verification code is then stored beginning with 
address a3. Finally all references to the offset subrou- 
tines are adjusted. Again, this is easily possible, since 
the information extracted e.g. from the object files is 
available. 

[0128] The security of the described method relies on 
the fact that an attacker is only in possession of the ex- 
ecutable file and does not have access to the extracted 
information known to the license server. Therefore, care 
must betaken not to leak information to an attacker and 
thus not to distribute the parts of the final stage of pro- 
gram creation from which the information has been ex- 
tracted. Thus, safety procedures typically include at 
least removing debug information or relocation informa- 
tion from executable files and not distributing debug in- 
formation files or object files to end-users. 
[0129] It is obvious, that distributing data from an ini- 
tial or an intermediate state of program creation can also 
facilitate the work of an attacker. However, data from 
these states is normally not distributed anyway. Hence, 
this has not been explicitly mentioned. 
[0130] It has to be understood that the described 
method may further be used to lift the burden of manu- 
ally adding verification code to a piece of software from 
a programmer by adapting the mechanism to embed 
one or more pieces of code- i.e. in particular verification 
code of any kind - and/or corresponding data into the 
software product. 

[01 31] In addition to executable files, the embedding 
method can also be applied to other representations of 
the software product, e.g. object files. 
[0132] In a further embodiment of the present inven- 
tion not only identification data are inserted between 
subroutines but also one or more additional subroutines 
will be added to the existing ones. These subroutines 
will then generate the identification data when being in- 
voked. The result will either be checked instantly by the 
calling subroutine or be stored as a variable in the data 
segment. For this purpose storage space for one or 
more additional variables in the data segment will be 
created in the process of fingerprinting. As an alternative 
to adding additional subroutines for the generation of 
identification data between any two subroutines, the 
code can also be embedded by one of the above de- 
scribed methods within one or more existing subrou- 
tines. Like for any of the obfuscating methods described 



above, this process has to be concluded by performing 
the necessary adjustments to all references to address- 
es in the code segment and the data segment, to reflect 
the modified layout of the code segment and the data 
segment. 

[01 33] To further obfuscate the layout of the download 
copy, the fingerprinting may include an embedding of 
non-functional code into randomly chosen subroutines, 
so that subroutines can no longer be tracked down by 
comparing different download copies of the same soft- 
ware product. 

[0134] It has to be understood, that transformations 
different from the transformations mentioned above are 
conceivable, sharing the common property of examining 
the previously extracted information. The transforma- 
tions that can thus be created have a much higher po- 
tential for complexity and are thus typically better suited 
to defend against attacks than transformations that do 
not have the extracted information at their disposal. 
[0135] Fingerprinting each individual download copy 
in the above described manner makes the licensing 
mechanism resistant to attacks with "cracks", small and 
simple programs for automatically removing, bypassing 
or outsmarting a licensing mechanism or copy protec- 
tion in a software product. These "cracks" can be down- 
loaded for many software programs from various web 
pages in the Internet. Their success is based on the con- 
dition, that all copies of a software program are identical, 
so that only one general "crack" program is necessary 
to disable the licensing mechanism of every copy of a 
certain software product. Due to the fact that a method 
to circumvent the protection mechanism for one down- 
load copy by successfully removing the verification code 
of the license enforcement and/or the watermark will not 
be applicable to any other download copy, because ac- 
cording to the present invention every copy is modified 
individually, such a general "crack" program will fail to 
circumvent the built-in license verification 
[0136] In an alternate embodiment of the present in- 
vention which is especially suitable for larger software 
packages only a small but important part of the program 
code is uploaded to the license server by the software 
supplier while the major rest of the software package is 
delivered to the customer in a different way, e.g. con- 
ventional media like CD-ROMs. Since the larger part is 
of no value without the smaller part that the customer 
downloads from the license server a secure software 
protection will also be guaranteed for this case. 
[0137] The code embedded into a download copy as 
described above may also be classified as verification 
code. In addition, two further kinds of verification code 
are typically embedded in a download copy in the course 
of the fingerprinting process, resulting in embedded ver- 
ification code that serves three main tasks. As dis- 
cussed above, the verification code has to verify the in- 
tegrity of the watermark applied during fingerprinting 
and to prevent tampering, and thus increase robustness 
of the software watermark against attacks. Further, the 
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verification code checks the integrity of the individual 
download copy to discover any modifications done to 
the original code and/or data. This part of the verification 
code guarantees the tamper-resistance of all built-in 
mechanisms. When abuse is detected, the license serv- s 
er could be informed of the misdoing and then generate 
an alert so that the incident can be investigated. Alter- 
natively, the executing program can be made to freeze 
or crash if modifications are detected. The third task of 
the verification code is querying the license server via a 
network in order to obtain permission to run and to stop 
program execution in case the permission is denied due 
to a lack of an appropriate license. This runtime mech- 
anism of the verification code is called license enforce- 
ment. In the process of downloading the software from 
the license server the code for the license enforcement 
varies slightly between any two distributed pieces of 
software, i.e. it will work slightly differently and will be 
embedded at different positions in the code. 
[0138] It has to be understood, that any data con- 
tained in any download copy - i.e. in particular code em- 
bedded in any download copy - which is identical for dif- 
ferent downloads may be supplied and stored separate- 
ly and thus be shared between more than one download 
copy. 

[0139] A general idea of license enforcement is to add 
appropriate verification code to a piece of software that, 
when the piece of software is started, queries the license 
server via a network, preferably the Internet, and re- 
quests permission to run. This allows an unprecedented 
flexibility in the handling of licenses, because modifica- 
tions in the license conditions and/or the number of li- 
censes effected by a user employing a browser-based 
license management interface, are immediately reflect- 
ed by the execution control mechanism on the license 
server. The examination of a request for a permission 
to run will always be carried out on the current status of 
the licensing conditions of a licensee. According to a 
special embodiment of the present invention the license 
server is constantly aware of all licensed programs that 
are running at a certain point in time. For this purpose 
the license enforcement part of the verification code 
contacts the license server once more when the user 
exits the piece of software thereby notifying it of the ter- 
mination of the program. 

[0140] This online license enforcement is considera- 
bly more resistant to "cracking" than a conventional off- 
line protection method explained above. To break the 
protection mechanism, an attacker would have to find a 
way for modifying the software such , that it becomes us- 
able without contacting the license server. Apart from 
obfuscating the inner workings of the software and to 
hide the verification code that interacts with the license 
server, in an especially advantageous embodiment of 
the present invention the user is provided with a copy of 
the software executable file, which lacks important parts 
of the code or has been rendered unusable in a different 
way. The missing pieces or information for repairing the 



unusable copy of the software are then automatically 
downloaded from the license server each time a permis- 
sion to run is granted. 

[0141] Additionally, a lesser degree of protection can 
still be achieved even in offline scenarios by only em- 
ploying the fingerprinting method described above to 
link an individual copy of a piece of software to the sub- 
ject acquiring the copy. Thus the subject will be discour- 
aged from illegitimately distributing bootlegs of his or her 
copy. 

[0142] The verification code for license enforcement 
consists of three sections, a start-up verification code 
responsible for asking the license server for a permis- 
sion to run, a permission validation code constantly 
checking the authenticity of the permission to run either 
explicitly or implicitly, and a shutdown verification code 
responsible for notifying the license server when the ex- 
ecution of the running piece of software has been ter- 
minated. 

[0143] It has to be understood that the embedding of 
any code or data needed for license enforcement can 
easily be performed using the same techniques that are 
employed for fingerprinting. 

[0144] When the start-up verification code queries the 
license server, the request contains identification infor- 
mation which has been invisibly embedded by the li- 
cense server into the piece of software during download. 
The identification information transmitted along with the 
query typically contains a unique identification of the li- 
censee, a unique identification of the software product, 
like e.g. "word processor XYZ, version 3.2" and a unique 
identification of the individual download of a piece of 
software that requests permission to run, like e.g. 
"download 121972". 

[0145] It is obvious that instead of transmitting three 
pieces of identifying information a single piece, e.g. a 
single identification number like "720201", can be sent 
to the license server, if the license server maintains a 
mapping from all single identification numbers to the 
corresponding pieces of original information. In the giv- 
en example, the server would map the identification 
number "720201 " to the triplet (licensee, "word proces- 
sor XYZ, version 3.2", "download 121972"). 
[0146] In principle the identification of the licensee 
can be of any kind like for instance his or her mail or e- 
mail address, but in case an increased level of privacy 
is desired, a pseudonym will be used instead. The pseu- 
donym typically is a customer number or a customer 
code. Preferably, the information for mapping the pseu- 
donym to the real identity of the licensee is only available 
to a trusted third party. By this means, the usage pattern 
for the license software is separated from the identities 
of the licensees. The third party like e.g. a trust centre 
will not be able to access the usage pattern for a li- 
censed software and the operator of the license server 
will not be able to access the real identity of a licensee. 
Thus the rights of licensees are protected. 
[0147] The identification information allows a flexible 
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enforcement of a plurality of licensing models. A soft- 
ware supplier may offer different varieties of the same 
type of software but with graded functionality. Depend- 
ing on the scope of the program functionality different 
licensing models may be employed. The licensing mod- 
el according to the type of software is then identified by 
the identification of the piece of software asking for a 
permission to run. The identification of the individual 
download of a piece of software is used to discriminate 
between different installations of the same piece of soft- 
ware which have been made by the same licensee. 
[0148] Assumed, the licensee is a small company 
which owns a license to use the software package "word 
processor XYZ, version 3.2" a maximum of three times 
simultaneously. The system administrator however has 
downloaded and installed the word processor five times, 
one copy on each one of his five desktop computers. 
Because the company owns a floating license, it is al- 
lowed to use the word-processor on each one of the five 
desktop computers, but not on more than three at the 
very same time. In the case of this floating license, the 
license server could choose to only consider the identi- 
fication of the licensee and the identification of the piece 
of software and would then grant a permission to run as 
long as the software is not running more than twice at 
the site of the company. If the maximum of running cop- 
ies of the piece of software was already reached, the 
license server would deny a permission to run a further 
copy. 

[0149] If the license is bound to a particular copy of 
the piece of software the license server will check on 
receiving a request to grant a permission to run, whether 
the individual download copy of the piece of software is 
already reported running. Assumed, the license server 
receives a request for "download 1 21 972" of "word proc- 
essor XYZ, version 3.2" and detects that the "download 
121972" is already running it will deny the permission to 
run. Most probably, the licensee must have made an il- 
licit second installation of the same piece of software on 
a second computer for using the software twice inde- 
pendently. Therefore, as a consequence of getting two 
separate requests for a permission to run for the same 
download, the license server now generates an alert 
and the incident will be investigated. 
[0150] Generally speaking, the license server re- 
ceives a request for a permission to run containing iden- 
tification information, searches for a license matching 
the identification information that allows the requesting 
copy to run and, in case it has found such a license, 
finally grants permission to run to the requesting copy. 
[0151] Advantageously, the license to be used is cho- 
sen by the server on a "best match first" basis. If there 
are e.g. two licenses available, one license for "down- 
load 121 972" of "word processor XYZ, version 3.2" and 
one assortment license for the office suite that consists 
of this word processor and other software, the former 
would be chosen, because it is more specific and does 
not prevent other users to run another program of the 



office suite at the same time. 

[0152] When a user starts his copy of the licensed 
software, a runtime version of the copy is loaded from 
persistent storage, e.g. a hard disc, into the memory of 

5 the computer. When the actual program is being exe- 
cuted, the start-up verification code contacts the license 
server. To this, in a preferred embodiment of the present 
invention the start-up verification code sends a request 
ticket to the license server. A first request ticket R1 is 

10 already embedded during download in the individual 
download copy by the download control software. On 
receiving the request ticket, the license server verifies 
its authenticity by comparing its content with the asso- 
ciated data stored during download of the individual 

is download copy. If the license server cannot validate the 
request ticket, it sends a command to the requesting 
start-up verification code for terminating the execution 
of the individual download copy. In the other case, the 
license server searches for a license that grants the re- 

20 questing copy permission to run and responds by trans- 
mitting a runtime ticket to the start-up verification code 
if such a license has been found. 
[0153] The start-up verification code stores the re- 
ceived runtime ticket in the data segment and/or the 

25 code segment of the runtime version of the executable 
file. The storage space for receiving the ticket data has 
already been created in the course of fingerprinting at 
the download of the piece of software. 
[01 54] A simple way to bypass th e software protection 

30 established with the license enforcement mechanism is 
to establish a fake license server set up with a trustwor- 
thy reproduction of the original license server, but which 
will always grant permission to run without verifying 
whether a corresponding license exists and will take 

35 care that all requests are re-directed to it. An attacker 
could therewith undermine the license enforcement 
mechanism. To eliminate any possibility of attacks like 
this, the verification code contains program code for ver- 
ifying a received ticket. This ticket verification code is 

40 embedded into numerous different locations within the 
code segment or e.g. into a plurality of subroutines and/ 
or as separate code between any two subroutines dur- 
ing download. The task of the ticket verification code is 
to verify the integrity of a received ticket so that it can 

45 be guaranteed, that the ticket was received from the le- 
gitimate license server. To verify, whether the legitimate 
license server or a fake license server issued a given 
ticket, any ticket is digitally signed when issued by the 
license server for example using public key cryptogra- 

so phy. If using a public key cryptosystern, the server signs 
the ticket with a private key and the ticket verification 
code verifies the signature with the corresponding public 
key when receiving the ticket. 

[0155] To further increase the level of security, meta- 
55 verification code is embedded to the individual down- 
load copy of a piece of software in the course of finger- 
printing. It makes the verification code tamper-proof by 
verifying the verification code and uncovering any at- 
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tempts to modify parts of it. The m eta- verification code 
typically includes checksum evaluation over selected 
parts of the code segment, which contains one or more 
parts of the verification code. 

[01 56] The ticket verification code is also part of the 5 
permission validation code, which regularly verifies the 
authenticity of the runtime ticket stored in the data seg- 
ment. To make it even harder for attackers to reverse 
engineer the software enforcement mechanism, the 
permission validation code makes some subtle modifi- 
cations to the run time environment of the running pro- 
gram when identifying a faked runtime ticket. The mod- 
ification to the runtime environment will cause the pro- 
gram to crash or freeze sooner or later. 
[0157] In a further preferred embodiment of the 
present invention, the ticket verification code as well as 
the permission validation code placed in the download 
copy is distributed over many different locations within 
the code segment, thus making it more difficult for soft- 
ware pirates to discover all of its parts, a necessary con- 
dition to invalidate the license enforcement mechanism 
and to obtain a stable version of a "cracked" piece of 
software. To prevent that an attacker intercepts the tick- 
et and provides this ticket to an illicit copy of the piece 
of software, the ticket verification code not only checks 
the authenticity and integrity of the ticket but also its ver- 
sion. When it finds out, that it is being submitted a ticket 
of the wrong version, it will carry on like in the case when 
it detects an illegitimate ticket. 
[0158] It is obvious from the above explanation, that 
the ticket verification code will not resume operation be- 
fore the start-up verification code acknowledges the re- 
ception of a new ticket. Otherwise the ticket verification 
code would only try to verify a ticket that has not yet 
been received. 

[0159] Finally, when the user terminates the execu- 
tion of the software program, the shutdown verification 
code will be invoked. Although its main responsibility is 
to inform the license server of the program termination, 
this message has to be certified to make sure that it does 
not originate from an untrustworthy location. A primitive 
notification of a program termination does not prevent 
from tricking the software protection by simply sending 
a termination notice to the license server before starting 
a second copy of a piece of software. The license server 
therefore sends a log-off ticket during the start-up proc- 
ess along with the runtime ticket, which is also stored in 
the data segment and/or code segment of the runtime 
version of the software copy at the client's side. Then, 
to inform the license server of an imminent program ter- 
mination, the shutdown verification code just returns this 
previously obtained log-off ticket. The license server val- 
idates the received log-off ticket and memorises, that 
the respective software copy has been terminated. 
[0160] The log-off ticket enables the license server in 
a preferred embodiment of the present invention to be 
constantly aware of which download copies are execut- 
ing at any point in time. After permission to run has been 



granted to a download copy, the license server adds the 
identification of the download copy to the log, like e.g. a 
list of concurrently running programs associated with 
the corresponding license. As long as the number of en- 
tries in the log is smaller than the limit imposed by the 
license, the license may grant permission to run to fur- 
ther download copies. At receiving a log-off ticket from 
a download copy in the log, the corresponding entry is 
removed. In this way, the number of concurrently exe- 
cuting download copies can be limited and hence float- 
ing licenses and assortment licenses may easily be en- 
forced. 

[01 61] Generally, the exchange of tickets between the 
client and the license server forms a way of verifying the 
synchronisation between the license server and the 
downloaded copy of the piece of software. Fig. 11 illus- 
trates the ticketing mechanism of the license enforce- 
ment according to a preferred embodiment of the 
present invention. The first request ticket R1 is already 
inserted in the individual download copy during down- 
load from the license server. When a user starts his ac- 
quired software program for the first time, the start-up 
verification code contacts the server and submits in step 
S11 that request ticket R1 , which is validated by the li- 
cense server in short order. For a clear description of 
the process it is assumed, that all validations are suc- 
cessful. But it is to be understood, that an invalid ticket 
found will terminate the execution of the individual 
download copy sooner or later like described above. 
[0162] It is important to note that during the ticket ex- 
change two copies of the executable file exist. The first 
copy is located on persistent storage, e.g. a hard disc. 
The second copy has been created by the operating 
system loading the executable file into the memory of 
the computer after the corresponding program was in- 
voked by the user. The latter copy is actively executing 
and performing the ticket exchange. However, any mod- 
ifications to the executable file, e.g. changes in the ver- 
ification code, are carried out on the copy on persistent 
storage. Still, for future refinements, the described sys- 
tem comprises means for modifying the executing copy. 
[0163] The license server replies at the beginning of 
step S 12 by sending T1, a runtime ticket version 1 to 
the user's client. The verification code embedded in the 
user's software copy during download is already adapt- 
ed to verify the authenticity of T1 . But this code is not 
adapted to validate T2, aversion 2 runtime ticket. In ad- 
dition to T1 , the license server therefore sends TVC2, a 
piece of a modified verification code, which is stored on 
reception by the start-up verification code in the individ- 
ual download copy on the hard disc of the user's client. 
Thus, when the userstarts his program for a further time, 
the modified ticket verification code now expects the 
next highest version for the runtime ticket. Also the re- 
quest tickets reflect the number of program starts by 
showing corresponding version indicators. To assure 
synchronisation between the status of the end-user's 
software copy and the license server, the license server 
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further transmits R2, a request ticket of version 2 along 
with T1 and the modified piece of verification code. Fi- 
nally it further sends L1 , a log-off ticket of version 1 
which is typically stored in the data segment and/or code 
segment of the runtime version of the user's software 5 
copy and its authenticity is verified. The start-up verifi- 
cation code now terminates its operation, ending step S 
12. 

[01 64] The actual program starts in step S 1 3 whereby 
the permission validation code repeatedly validates T1 
during program execution. As soon as the user exits his 
program in step S 14, the shutdown verification code 
starts and returns the previously received L1 to the li- 
cense server, which in its turn logs the information about 
the program termination. If a malicious subject tries to 
cheat the license enforcement by feigning the termina- 
tion of the program execution, it will not be able to use 
a copy of the runtime version for a second run because 
this copy would ask for a permission to run producing 
request ticket R1 while the license server would expect 
being showed request ticket R2, which can only be sup- 
plied by the software copy modified on the hard disc. 
[0165] Alternatively, the new request ticket R2 could 
be transmitted by the server in reply to L1, i.e. during 
the shutdown phase. The drawback of this variant is, 
however, that if the software program crashes while be- 
ing used, i.e. before the shutdown phase, it will not be 
in possession of a valid request ticket when invoked for 
the next time. 

[01 66] Generally speaking, when the program is start- 
ed, the request ticket Rx obtained from the license serv- 
er in the course of the preceding start-up is now trans- 
mitted by the start-up verification code. In return the 
start-up verification code receives the new runtime ticket 
Tx, the new piece of modified verification code TVCx+1 , 
the appropriate log-off ticket Lx for this x-th run of the 
program, and the request ticket for the next (x+1)-th run 
Rx+1 . On terminating this run of the program the shut- 
down verification code returns Lx. 
[01 67] It is to be noted, that storing one or more of the 
tickets within the download copy is just one of the op- 
tions for carrying out the present invention. Alternatively, 
a ticket can e.g. be stored in an extra file or within an 
already existing file on the client computer, whereby not 
all tickets have to be stored in the same way. 
[0168] Advantageously, the server does not only keep 
track of the current version of the tickets, respectively 
the number of times the software product has been ex- 
ecuted, but in addition monitors the number of execu- 
tions of each subroutine within the executable file. To 
this purpose, a counter is implemented - typically by em- 
bedding code during the process of fingerprinting - at 
the beginning of each subroutine, the value of which is 
initialised to zero in the individual software copy being 
downloaded from the server. While the software execut- 
able file is being run the counter of each subroutine that 
contains a counter is incremented by one on each invo- 
cation of the subroutine. The server obtains the counter 



values at the process of program termination. These val- 
ues may be used for statistical surveys, e.g. to find out 
which subroutines are commonly used and which are 
obviously considered unnecessary by the end-users. 
[0169] In a particularly advantageous embodiment of 
the present invention the individual download copy rep- 
resents a version of the original executable software file 
which lacks at least some sections of code and/or data 
or which has been made unfunctional in other ways. At 
starting the program, the start-up verification code or- 
ders the reinstatement of the program code. The license 
server examines the request and decides if the client, 
respectively the start-up verification code is to be sup- 
plied with program code and/or data repairing the down- 
load copy at least partially. 

[01 70] Conveniently, the order for a reinstatement of 
the program code is transmitted together with the actual 
request ticket. To enhance the resistance of the protec- 
tion mechanism against attacks, only the runtime ver- 
sion of the download copy is repaired, while the copy of 
this file on the permanent storage medium like the hard 
disc stays unchanged. In a further particularly preferred 
embodiment of the present invention, the code for re- 
pairing the download copy additionally modifies the 
copy of the related file on the permanent storage medi- 
um, so that a different repair code is necessary at the 
next start of the program. A malicious subject intercept- 
ing the repair code one time is thereby not yet enabled 
to create an executable version of the program code. 
[0171] In a further advantageous embodiment of the 
present invention the license server communicates with 
the client respectively the verification code not only by 
exchanging tickets, but in addition asks itto perform cer- 
tain tasks. The results obtained from it are then taken 
by the license server as a basis for further decisions. 
The license server e.g. asks the client to calculate the 
checksum over a subroutine beginning at a certain ad- 
dress and/or the value of a byte at a certain location. At 
a correct result, the license server concludes that the 
code has not been tampered with. To improve tamper 
resistance even further, the server favourably interro- 
gates the client over several rounds. Only if the license 
server allows itself to be convinced of the integrity of the 
client's answers, will it pass on the information neces- 
sary for the client to continue the program execution. 
[0172] In addition, the tasks may include modifica- 
tions to the individual download copy or other data re- 
ceived from the license server, like tickets. In this case, 
an attacker potentially faces a target changing dynami- 
cally with each invocation ofthe download copy and thus 
the robustness of the license enforcement mechanism 
against attacks is improved. 

[0173] In particular, the tasks to be performed can be 
specified by sending executable code to the client, hav- 
ing the client execute the code, which e.g. calculates a 
checksum, and optionally asking the client to return the 
result of the code execution, e.g. the calculated check- 
sum. 
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[0174] In a further particularly advantageous embod- 
iment of the present invention a virtual machine is im- 
plemented in the verification code like e.g. a Java Virtual 
Machine, allowing a maximum of flexibility, platform-in- 
dependence and client-side security in realising these 5 
interactive interrogation procedures by providing byte- 
code that can optionally be executed in a sandboxed 
environment provided by the virtual machine. 
[0175] A subject with a view to use one and the same 
copy of its download copy several times on different 
computers concurrently, might find a way to prevent ter- 
mination of the runtime version of the respective pro- 
gram although the client returned the log-off ticket to the 
license server. It may then copy the version of the down- 
load copy on the hard disc to another computer and start 
it there, which will work, because the license server is 
convinced that the program has been terminated cor- 
rectly before. The subject might continue this operation 
and use the software in an unlimited number owning on- 
ly one license. Therefore, the license server when in- 
formed of a program termination effects according to a 
preferred embodiment of the present invention the runt- 
ime version of the download copy to be modified such, 
that it can no longer be executed. Practically, when the 
shutdown verification code informs the license server of 
the impending program termination, the latter enforces 
modifications on the runtime copy employing one or 
more of the above described methods. As an example, 
the license server demands that the shutdown verifica- 
tion code overwrites a central subroutine and checks 
this by requesting a checksum over an appropriate sec- 
tion of the code. Again, this can be repeated several 
over several rounds until the server is sure that the mod- 
ified runtime copy of the software is unusable and logs 
that the program has been terminated. 
[01 76] Assumed, that an end-user has transferred his 
download copy of a piece of software from a first com- 
puter to a second computer, and now starts the program 
on the second computer after quitting it on the first, he 
can be sure that a permission to run will be granted by 
the license server. Once he has started the software 
from the second computer another subject trying to re- 
start the first copy on the first computer will not be able 
to run this piece of software again because it will be de- 
tected as an infringement of the licensing conditions. If 
the licensee intends to use his piece of software on the 
first computer again, he has to transfer the last copy of 
it from the second computer back to the first computer. 
By this means, a licensee can be sure that his rights as 
the only beneficiary of the acquired software are pro- 
tected. 

[0177] At last, it is to be considered that the connec- 
tion between client and server can fail during a start-up 
orshutdown procedure orthat the actual program crash- 
es during execution. Assumed that the request ticket got 
lost on its way from the license server to the client, due 
to an incident like e.g. a system crash of the client or an 
interruption in the connection between server and client, 



then, on its next program start the client requests a per- 
mission to run from the license server with an already 
outdated version of the request ticket according to the 
server's state. The reverse situation develops when a 
log-off ticket sent by a client does not reach the license 
server. The latter might suspect an illegal second use of 
the same software copy when the program requests a 
permission to run the next time. 
[0178] Theses scenarios are likely to happen at the 
present technological state of the art, so that a recovery 
mechanism is provided in an especially preferred em- 
bodiment of the present invention. This recovery mech- 
anism eases the restrictions set by the license server by 
it accepting also an old or not yet valid request ticket or 
allowing a certain download copy to be started again al- 
though no corresponding log-off ticket was received af- 
ter the last program invocation for a few but limited 
times. If the limit is exceeded by an end-user, his license 
will be frozen automatically. The end-user then has to 
contact an authorised subject to clarify the situation and 
to get his license released. 

[0179] The present invention ensures a reliable soft- 
ware protection for one by controlling the trading of the 
software licenses and on the other hand by controlling 
each individual use of a piece of software, whereby the 
legitimacy of each download software file can be verified 
by means of a verification code and identifying data em- 
bedded in the download software file in the form of an 
individualised watermark. 



Claims 

1 . A method for software license management and on- 
line software license enforcement comprising the 
steps of: 

a) providing individual licenses for regulating 
the use of a software product, 

b) controlling a transfer of licenses, 

c) providing individualised copies of said soft- 
ware product for download, and 

d) monitoring an execution of each individual- 
ised copy of said software product in agree- 
ment with the individual license terms. 

2. A method forsoftware license management and on- 
line software license enforcement according to 
claim 1 , 

characterised in 

that said individualising step comprises embedding 
information in said individualised copies of said soft- 
ware product. 

3. A method forsoftware license management and on- 
line software license enforcement according to 
claim 1 or 2, 

characterised in 



15 



20 



25 



30 



35 



40 



45 



50 



21 



41 



EP 1 243 998 A1 



42 



that said individualising step generates a uniquely 
individualised copy of said software product for 
each download. 

4. A method for software license management and on- 
line software license enforcement according to 
claim 1, 2 or 3, 

characterised in 

that each subject joining the procedure of said soft- 
ware license management and online software li- 
cense enforcement is subject to register prior to be- 
ing granted access. 

5. A method of modifying one or more files of a soft- 
ware product, particularly in conjunction with a 
method of one of the claims 1 to 4 
characterised in 

that said modifying is at least partly based on infor- 
mation extracted from at least a part of data of one 
or more initial and/or intermediate and/or final 
states of the creation process of said software prod- 
uct. 

6. A method of modifying one or more files of a soft- 
ware product, according to claim 5, 
characterised in 

that said modifying comprises embedding informa- 
tion in at least one of said files. 

7. A method of modifying one or more files of a soft- 
ware product according to claim 5 or 6, 
characterised in 

that said data comprise data of one or more object 
files generated during the creation process of said 
software product. 

8. A method of modifying one or more files of a soft- 
ware product according to claim 5, 6 or 7, 
characterised in 

that said data comprise data of the debug informa- 
tion generated during the creation process of said 
software product. 

9. A method of modifying one or more files of a soft- 
ware product according to one of the claims 5 to 8, 
characterised in 

that said data comprise data of the relocation infor- 
mation generated during the creation process of 
said software product. 

10. A method of modifying one or more files of a soft- 
ware product according to one of the claims 5 to 9, 
characterised in 

that said modifying is carried out on one or more 
executable files of said software product. 

11. A method of modifying one or more files of a soft- 
ware product according to oneoftheclaims5to 10, 



characterised in 

that said modifying comprises a modification of the 
arrangement of the subroutines within said software 
product. 

5 

12. A method of modifying one or more files of a soft- 
ware product according to one of the claims 5 to 11 , 
characterised in 

that said modifying comprises a modification of the 
10 arrangement of the variables within said software 
product. 

13. A method of modifying one or more files of a soft- 
ware product according to one of the claims 5 to 1 2, 

15 characterised in 

that said modifying comprises inserting data and/ 
or code between any two subroutines within said 
software product. 

20 14. A method of modifying one or more files of a soft- 
ware product according to one of the claims 5 to 1 3, 
characterised in 

that said modifying comprises inserting data and/ 
or code between any two variables within said soft- 
25 ware product. 

15. A method of modifying one or more files of a soft- 
ware product according to one of the claims 5 to 1 4, 
characterised in 

30 that said modifying comprises inserting data and/ 
or code into the code of one or more subroutines 
within said software product. 

16. A method of modifying one or more files of a soft- 
35 ware product according to one of the claims 5 to 1 5 , 

characterised in 

that data and/or code for testing the integrity of one 
or more parts of one or more modified files is em- 
bedded within said software product. 

40 

17. A method of modifying one or more files of a soft- 
ware product according to one of the claims 5 to 1 6, 
characterised In 

that said modifying comprises at least embedding 
45 a part of a piece of verification software. 

18. A license management software program compris- 
ing the steps of 

providing licenses, and 
so controlling a transfer of licenses. 

19. A license management software program according 
to claim 18, 

characterised by 
55 regulating a distribution policy. 

20. A license management software program according 
to claim 18 or 19, 
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characterised in 

that a provision of licenses comprises an upload of 
one or more licenses to the license management 
software program. 

21 . A license management software program according 
to claim 18, 19 or 20, 

characterised in 

that a provision of licenses comprises a manually 
triggered generation of a license by the license 
management software program. 

22. A license managementsoftware program according 
to one of the claims 1 8 to 21 , 
characterised In 

that a provision of licenses comprises an automatic 
generation of a license on demand. 

23. A license management software program according 
to one of the claims 1 8 to 22, 
characterised in 

that in a registration procedure each subject ac- 
cessing said license management software pro- 
gram is assigned one or more roles. 

24. A license management software program according 
to claim 23, 

characterised in 

that uploading and/or enabling a generation of li- 
censes is allowed to a subject assigned the role of 
a software supplier only. 

25. A license managementsoftware program according 
to claim 23 or 24, 

characterised in 

that initiating a provision of licenses comprises de- 
fining one or more operations on said licenses. 

26. A license management software program according 
to claim 25, 

characterised in 

that initiating a provision of licenses comprises link- 
ing said defined operations or subsets thereof to 
one or more roles such, that each subject enlisted 
in one or more of said roles is capable of performing 
the operations linked to its role or roles. 

27. A license management software program according 
to claim 26, 

characterised in 

that the operations available to a subject further de- 
pend on attributes of said subject different from its 
role or roles. 

28. A license managementsoftware program according 
to one of the claims 23 to 27, 
characterised in 

that depending on the role assigned to a subject, 



said subject may further restrict the license condi- 
tions of a license. 

29. A license management software program according 
5 to one of the claims 23 to 28, 

characterised in 

that said assignment of one or more roles to said 
subject comprises a verification of an authorization 
of said subject obtained separately. 

10 

30. A license managementsoftware program according 
to one of the claims 23 to 29, 
characterised in 

that said assignment of one or more roles to said 
15 subject comprises a verification of an authorization 
of said subject by means of a digital signature. 

31 . A license management software program according 
to one of the claims 18 to 30, 

20 characterised in 

that for the purpose of monitoring licenses, each 
license holds information about the identity of one 
or more downloaded individualised copies of the 
software product licensed by said license. 

25 

32. A download control software program for providing 
an individual download copy of a software product 
by individually modifying a copy of a master-copy 
of said software product for download from a server 

30 according to a method of one of the claims 5 to 1 7. 

33. A download control software program according to 
claim 32, 

characterised in 
35 that said modifying creates a uniquely modified 
copy of said master-copy for each download. 

34. A download control software program according to 
claim 32 or 33, 

40 characterised in 

that said modifying comprises embedding informa- 
tion which unambiguously links said individual 
download copy of a software product to a subject. 

45 35. A download control software program according to 
claim 32, 33 or 34, 
characterised in 

that said modifying comprises embedding informa- 
tion which unambiguously identifies said master- 
50 copy of said software product. 

36. A download control software program according to 
one of the claims 32 to 35, 
characterised in 
55 that said modifying comprises embedding informa- 
tion which unambiguously identifies said individual 
download copy of said software product. 
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37. A download control software program according to 
one of the claims 32 to 36, 

characterised In 

that at least some of the parts of said individual 
download copy being invariant to different down- 
loads are kept in one or more files separate from 
said individual download copy of said software 
product. 

38. An execution control software program for linking 
an individual download copy of a software product 
requesting permission to run to a matching license, 
comprising the steps of 

obtaining identification information from said indi- 
vidual download copy of a software product before 
or while it is being executed, 
evaluating licenses matching said identification in- 
formation, and 

if at least one of said licenses grants use of said 
individual download copy of a software product, 
transmitting approval to said individual download 
copy of a software product. 

39. An execution control software program according 
to claim 38, 

characterised in 

that said matching licenses are evaluated on a 
"best match firsf'-basis. 

40. An execution control software program according 
to claim 38 or 39, 

characterised by 

said approval being code and/or data transmitted 
from said execution control software program to 
said individual download copy of a software product 
necessary to obtain a fully usable runtime version 
of said individual download copy of a software prod- 
uct. 

41. An execution control software program according 
to claim 38, 39 or 40, 

characterised by 

said approval being a runtime ticket transmitted 
from said execution control software program to 
said individual download copy of a software prod- 
uct. 

42. An execution control software program according 
to one of the claims 38 to 41 , 
characterised In 

that transmitting approval requires successful vali- 
dation of a request ticket supplied by said individual 
download copy of a software product. 

43. An execution control software program according 
to one of the claims 38 to 42, 
characterised in 

that transmitting approval requires successful vali- 



dation of the integrity of said individual download 
copy of a software product. 

44. An execution control software program according 
5 to one of the claims 38 to 43, 

characterised in 

that changes are effected by said execution control 
software to be made to said individual download 
copy of a software product and/or to one or more of 
10 the stored tickets. 

45. An execution control software program according 
to one of the claims 38 to 44, 
characterised in 

15 that receiving a valid log-off ticket from said individ- 
ual download copy of a software product is treated 
as a notification of the termination of an execution 
of said individual download copy of a software prod- 
uct. 

20 

46. An execution control software program according 
to claim 45, 

characterised in 

that said individual download copy of a software 
25 product has to prove its runtime version unusable 
before said log-off ticket is accepted. 

47. An execution control software program according 
to claim 45 or 46, 

30 characterised in 

that for each license said execution control soft- 
ware maintains a log of all executing individual 
download copies of software products that have 
been granted permission to run by said license. 

35 

48. An execution control software program according 
to claim 47, 

characterised In 

that said log is considered by the execution control 
40 software when deciding whether a license grants 
permission to run to a requesting individual down- 
load copy of a software product or not. 

49. An individual download copy of a software product 
45 created by individually modifying a copy of a mas- 
ter-copy of said software product for download from 
a server according to a method of one of the claims 
5 to 17. 

so so. An individual download copy of a software product 
according to claim 49, 
characterised in 

that said individual download copy of a software 
product is a uniquely modified copy of said master- 
55 copy. 

51. An individual download copy of a software product 
according to claim 49 or 50, 
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characterised in 

that said individually modifying comprises embed- 
ding identifying information in said inividual down- 
load copy of a software product. 

52. An individual download copy of a software product 
according to claim 49, 50 or 51 , 
characterised in 

that said individually modifying comprises embed- 
ding at least a part of a piece of verification code for 
carrying out the steps of: 

a) querying an execution control software pro- 
gram to obtain a permission to run at a start-up 
of said individual download copy of a software 
product, and 

b) continuing an execution of said individual 
download copy of a software product if a 
permission to run is obtained and aborting said 
execution otherwise. 

53. An individual download copy of a software product 
according to claim 52, 

characterised in 

that said individual download copy of a software 
product notifies said execution control software pro- 
gram of an infringement of its integrity. 

54. An individual download copy of a software product 
according to claim 52 or 53, 

characterised in 

that said individual download copy of a software 
product forwards identification data while querying 
said execution control software program for a per- 
mission to run. 

55. An individual download copy of a software product 
according to claim 54, 

characterised in 

that said identification data comprise an identifica- 
tion of the licensee. 

56. An individual download copy of a software product 
according to claim 54 or 55, 

characterised in 

that said identification data comprise an identifica- 
tion of said master-copy of said software product. 

57. An individual download copy of a software product 
according to claim 54, 55 or 56, 
characterised in 

that said identification data comprise an identifica- 
tion of said individual download copy of a software 
product. 

58. An individual download copy of a software product 
according to one of the claims 52 to 57, 
characterised In 



that a request ticket is supplied with said query to 
obtain a permission to run. 

59. An individual download copy of a software product 
5 according to one of the claims 52 to 58, 

characterised in 

that a runtime ticket received from said execution 
control software program constitutes said permis- 
sion to run. 

10 

60. An individual download copy of a software product 
according to one of the claims 52 to 59, 
characterised in 

that a log-off ticket is received from said execution 
is control software program. 

61. An individual download copy of a software product 
according to claim 60, 

characterised in 
20 that said log-off ticket is returned to said execution 
control software program at the process of terminat- 
ing the execution of said individual download copy 
of a software product. 

25 62. An individual download copy of a software product 
according to one of the claims 58 to 61 , 
characterised In 

that at least a part of a piece of verification code is 
embedded in one or more subroutines to verify the 
30 validity of at least one type of ticket. 

63. An individual download copy of a software product 
according to one of the claims 49 to 62, 
characterised in 
35 that code embeded in one or more subroutines in- 
crements a counter particular to said subroutine 
each time said subroutine of said individual down- 
load copy of a software product is invoked. 

40 64. An individual download copy of a software product 
according to claim 63, 
characterised In 

that the reading of each of said counters is submit- 
ted to the execution control software program at the 
45 process of terminating the execution of said individ- 
ual download copy of a software product. 

65. An individual download copy of a software product 
according to one of the claims 49 to 64, 

so characterised in 

that at least a part of a piece of meta-verification 
code is embedded in one or more subroutines to 
verify the integrity of at least a part of said individual 
download copy of a software product. 

55 

66. An individual download copy of a software product 
according to one of the claims 49 to 65, 
characterised by 
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a provision of means for an execution of code sup- 
plied by the execution control software program. 

67. An individual download copy of a software product 
according to claim 66, 

characterised by 

a provision of means for returning a result of the ex- 
ecution of said code to said execution control soft- 
ware program. 

68. A server for providing a software license manage- 
ment and an online software license enforcement 
in accordance to a method described in one of the 
claims 1 to 17, comprising means for the application 



a) a license management software program ac- 
cording to one of the claims 1 8 to 31 , and/or 

b) a download control software program ac- 
cording to one of the claims 32 to 37, and/or 

c) an execution control software program ac- 
cording to one of the claims 38 to 48. 
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Figure 2 a/1 



Policy for educational licenses (license type "Educ") 
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Policy for commercial licenses (license type "Comm") 
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Figure 2a/2 



Policy for dealer licenses (license type "Deal") 
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Fig. 2b 



Characteristics of available license classes for a selected product suite consisting of 
a word processor, a spreadsheet and a database application. 



Class 


Type 


Product(s) 


# Simult Users 


# Usages 


Validity Period 


EDU-1 


Educ 


Word Processor 1.0 
Spreadsheet 1 .0 
Database 1.0 


50 


unlimited 


5a 
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Educ 


Word Processor 1.0 
Spreadsheet 1 .0 
Database 1 .0 


1 


unlimited 


unlimited 


EVA-1 


Eval 


Word Processor 1.0 
Spreadsheet 1 .0 
Database 1 .0 


1 


50 


30d 


COM-1 


Comm 


Word Processor 1 .0 
Spreadsheet 1 . 0 
Database 1 .0 


10 


unlimited 


5a 


COM-2 


Comm 


Word Processor 1 .0 
Spreadsheet 1.0 
Database 1 .0 


50 


unlimited 


5a 


COM-3 


Comm 


Word Processor 1 .0 
Spreadsheet 1 .0 
Database 1 .0 


unlimited 


unlimited 


5a 


DEA-1 


Deal 


Word Processor 1 .0 
Spreadsheet 1.0 
Database 1 .0 


1 


unlimited 


1a 
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Fig. 2C 
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[The following lines were copied from the license class "EPU-1" on creation.]: 



Licensed software 


Word Processor 1 .6 




Spreadsheet 1 .0 




Database 1 .0 


Maximal number of concurrent users 


50 


Maximal number of program invocations 


unlimited 


Valid through 


March 2006 



[The following lines were copied from the license policy corresponding to the license 
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